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I. 


INTRODUCTION 


A.  BACKGROUND 

While  computer  hardware  productivity  continues  to 
improve,  software  productivity  is  unable  to  "hold  its  own." 
[Ref.  l:p.  43]  This  is  true  at  a  time  when  there  is  an  ever 
increasing  demand  for  development  and  implementation  of 
software  applications.  The  demand  for  software  will 
continue  to  grow  at  a  huge  rate;  one  estimate  places  that 
figure  at  25  percent  annually  [Ref.  2:p.  31]. 

Increase  in  the  demand  for  software  is  not  the  only 
problem  facing  the  software  industry.  Other  concerns 
include  software  that  costs  more  than  it  is  budgeted  for, 
software  that  is  delivered  late  or  not  at  all,  and  software 
that  doesn't  meet  user  requirements.  All  these 
considerations  lead  to  the  concern  that  the  United  States 
will  be  "unable  to  produce  the  software  it  needs."  [Ref. 

2 : p .  31] 

In  order  to  meet  the  demand  facing  the  software  industry 
while  addressing  the  concerns  listed  above,  it  is  necessary 
that  software  professionals  understand  the  software 
development  process.  Only  after  this  has  taken  place  will 
economical  and  timely  development  of  software  applications 
be  feasible. 
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Understanding  the  software  development  process  is  not  as 
simple  as  it  may  seem.  As  Roberts  has  pointed  out  [Ref. 

3:p.  293],  project  management  techniques  are  often  based  on 
a  single  feedback  loop,  much  like  that  illustrated  in  Figure 
1  [Ref.  4:p.  1427]. 
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Figure  1.  A  Model  of  Software  Project  Management 


Actual  software  development  processes  are,  however,  much 
more  complex  and  involve  more  interdependent,  interrelated 
variables  [Ref.  4:p.  1427].  A  more  realistic  model  of  the 
software  development  process,  illustrating  some  of  these 
variables  and  their  interdependence,  is  shown  in  Figure  2 
[Ref.  4:p.  1428].  More  importantly,  understanding  the 
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behavior  of  this  process  and  these  interrelationships  "is 
complex  far  beyond  the  capacity  of  human  intuition."  [Ref. 
4 :p.  1428] 


Figure  2.  Amendment  to  the  Project  Management 
Model 


While  understanding  a  single  project  is  beyond  the 
capability  of  human  beings,  understanding  multiple  projects 
running  in  parallel  or  concurrently  is  even  more  difficult. 
Yet  it  is  in  just  this  situation  that  many  organizations 
find  themselves.  As  Archibald  states,  "It  is  rare  to  find  a 
project  that  exists  by  itself  without  interaction  with  other 
projects."  [Ref.  5:p.  59]  He  continues  to  emphasize  that 


the  "basic  problems  result  from  competition  between... 
projects  for  resources...."  [Ref.  5:p.  59]  Most  software 
organizations  are  in  the  process  of  developing  many  projects 
at  any  time?  effective  management  of  these  projects  is  not 
possible  without  an  understanding  of  how  they  are 
interrelated. 

B.  THESIS  OBJECTIVES 

The  primary  objective  of  this  thesis  is  expansion  of  the 
human  resource  management  subsystem  of  the  System  Dynamics 
model  of  software  project  management,  presented  in  Reference 
4.  The  model  will  be  described  in  depth  in  Chapter  II. 

This  expansion  is  to  enable  the  model  to  demonstrate  the 
effects  of  manpower  decisions  in  a  multiproject  environment. 
It  will  allow  modelling  of  an  organization  through  which 
many  projects  are  being  managed  at  the  same  time.  These 
pi ejects  may  have  different  starting  dates,  different 
amounts  of  resources  (time,  money) ,  and  different 
characteristics  (delivered  source  instructions) . 

Through  this  expansion  of  the  existing  model, 
information  can  be  gleaned  in  the  following  areas: 

1.  Effects  of  management  manpower  decisions  on  the 
allocation  of  resources  to  different  projects  in  a 
software  development  arena. 

2.  Identification  of  the  additional  variables  necessary 
to  reflect  manpower  decisions  resulting  in  movement 
between  projects  and  within  an  organization. 

3.  Insights  to  be  gained  on  optimizing  the  staffing 
function  in  a  multiproject  environment. 
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C.  METHODOLOGY 


Prototyping  will  be  used  in  developing  this  thesis. 
Initially,  the  redesigned  human  resource  management 
subsystem  will  be  implemented  in  an  existing  smaller  model. 
This  will  be  an  iterative  process  with  continuing 
adaptations  being  made  to  the  code  as  analysis  of  results 
indicates  the  necessity  for  these  changes  to  make  the  model 
a  more  accurate  reflection  of  reality.  Once  an  acceptable 
design  is  achieved,  it  will  be  incorporated,  along  with  any 
necessary  adaptations,  to  a  more  detailed  model.  A 
description  of  this  enhanced  model  can  be  found  in  Chapter 
III.  Then  experimentation  with  staffing  policies  will  be 
conducted;  results  of  these  experiments  will  be  presented  in 
Chapter  IV. 
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II.  THE  SYSTEM  DYNAMICS  MODEL  OF  SOFTWARE 
PROJECT  MANAGEMENT 


A.  SYSTEM  DYNAMICS 

The  software  project  management  model  which  is  to  be 
enhanced  is  based  on  the  concept  of  system  dynamics.  As 
Roberts  states,  "System  dynamics  is  the  application  of 
feedback  control  systems  principles  and  techniques  to 
managerial,  organizational,  and  socioeconomic  problems." 
[Ref.  3:p.  3]  The  philosophy  of  the  system  dynamics 
approach  is  that  the  behavior  of  an  organization  is  a 
reflection  of  its  structure,  including  policies  and 
traditions  [Ref.  3:p.  4].  Yet  another  aspect  of  system 
dynamics  is  the  idea  that  one  can  most  effectively  view 
organizations  in  terms  of  their  flows  (such  as  the  flow  of 
people  into  and  out  of  the  workforce)  and  the  cause-and- 
effect  chains  which  can  be  traced  through  these  flows  [Ref. 

3  :  p .  5  ]  . 

These  organizational  relationships  are  of  two  types — 
levels  and  rates.  A  level  represents  accumulations  of 
resources  over  time  of  flows  or  changes  that  come  into  and 
out  of  that  level  [Ref.  3:p.  195].  In  the  software 
development  application  of  the  svstem  dynamics  approach,  one 
example  of  a  level  is  the  number  of  people,  or  workforce 
level,  involved  in  the  development  of  a  project.  A  rate 
includes  any  "flow,  decision,  action,  or  behavior  that 
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changes  over  time  as  a  function  of  the  influences  acting 
upon  it."  [Ref.  3:p.  19]  An  example  of  a  rate  in  the  model 
is  that  of  assimilation  rate — the  rate  at  which  workers  are 
assimilated  into  the  workforce.  Modelling  of  these 
organizational  relationships  is  the  first  step  in  the 
application  of  the  system  dynamics  approach. 

The  next  step  for  a  system  dynamics  project  is  to  apply 
computer  simulation  techniques  to  the  model.  These 
techniques  enable  the  user  to  understand  the  complex 
interrelationships  existent  in  a  feedback  system.  According 
to  Roberts,  a  feedback  system  exists  whenever  an  individual 
takes  an  action  which  will  later  influence  other  actions  he 
takes  [Ref.  3:p.  7].  For  example,  in  software  development, 
a  project  manager  may  decide  to  begin  a  project  with  only 
five  programmers.  This  decision  will  affect  whether  the 
project  remains  on  schedule  which  will  in  turn  affect 
whether  the  project  manager  needs  to  hire  more  programmers. 
Figure  1  provides  an  example  of  a  very  simplistic  feedback 
loop.  Figure  2  portrays  a  feedback  loop  which  is  more 
realistic  and  obviously  more  difficult  for  a  human  being  to 
comprehend.  It  is  for  this  reason  that  computer  simulation 
is  necessary  to  reflect  the  interrelationships  in  the  real 
system. 

Dynamo  is  the  computer  simulation  language  in  which  the 
software  project  management  model  was  written.  It  is  a 
computer  program  which  is  capable  of  executing  continuous 
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simulation  models.  Dynamo  was  developed  at  the  Sloan  School 
of  Management  at  M.I.T.  in  the  late  1950 's  [Ref.  6:p.  viii]. 
According  to  Roberts,  Dynamo  is  ”a  major  asset  to  the  system 
dynamics  effort.”  [Ref  3:p.  5] 

B.  MODEL  STRUCTURE  AND  BEHAVIOR 

The  System  Dynamics  model  of  software  project  management 
was  developed  to  aid  the  software  project  manager  in 
understanding  the  software  development  process  and  the 
dynamic  behavior  of  a  project.  As  previously  mentioned, 
the  software  development  process  includes  many  complex, 
interrelated  variables.  Understanding  and  tracing  the 
relationships  among  these  variables  is  beyond  the  capability 
of  human  intuition  [Ref.  7:p.  6].  This  model  provides  the 
necessary  information  to  allow  human  beings  to  view  the 
results  of  these  interrelationships  and  the  effects  of  the 
many  variables  on  each  other. 

It  is  important  to  clarify  two  points.  First,  the  focus 
of  the  model  is  on  the  aspects  of  the  project  that  change 
over  time  such  as  workforce  level  rather  than  aspects  which 
remain  constant,  such  as  programming  language.  Second,  this 
model  was  not  intended  to  provide  "point-predictions.”  It 
is  descriptive  rather  than  prescriptive  in  nature  and  was 
designed  to  be  used  in  understanding  relationships  rather 
than  predicting  them.  [Ref.  7:p.  8] 

The  model  integrates  the  multiple  functions  of  software 
development  to  include  both  management-type  functions  such 
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as  planning  and  controlling  and  software  production-type 
functions  such  as  coding  and  testing  [Ref.  7:p.  6],  A 
description  of  how  these  functions  are  integrated  will  be 
presented  later  in  this  chapter. 

Finally,  the  model  allows  the  manager  to  perform 
sensitivity  analysis  by  changing  the  values  of  variables  and 
viewing  the  results  of  these  changes.  This  capability  is 
particularly  important  when  studying  feedback  systems  since 
they  "exhibit  behavior  that  cannot  be  anticipated  by 
studying  the  components  of  the  system  in  isolation."  [Ref. 
6:p.  1]  The  results  of  changing  a  variable  cannot  be 
predicted  by  the  manage-  solely  on  the  basis  of  the  new 
value  of  the  variable;  the  model  gives  the  manager  the 
ability  to  see  the  overall  results  of  any  changes  and  how 
those  changes  affect  many  variables. 

The  System  Dynamics  model  of  software  project  management 
was  developed  on  the  basis  of  interviews  of  software  project 
managers  in  five  organizations.  It  comprises  four 
subsystems  as  depicted  in  Figure  3  [Ref.  7:p.  8a].  These 
include  the  human  resource  management  subsystem,  the 
software  production  subsystem,  the  controlling  subsystem, 
and  the  planning  subsystem.  Some  of  the  interrelationships 
among  the  four  subsystems  are  also  illustrated  in  Figure  3. 

A  brief  description  of  each  subsystem  follows.  A  more 
complete  discussion  of  the  model  can  be  found  in  Reference 
4. 
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Figure  3.  The  System  Dynamics  Model  of  Software 
Project  Management 


1 •  Human  Resource  Management  Subsystem 

The  human  resource  management  subsystem  models  the 
hiring,  training,  assimilation,  and  transfer  of  the 
workforce.  In  this  subsystem,  a  distinction  is  made  between 
newly  hired  and  experienced  workforce,  as  new  team  members 
tend  to  be  less  productive  than  experienced  ones.  [Ref. 

2 :p.  102] 

The  differentiation  between  new  and  experienced 
workers  also  allows  modelling  of  the  training  process 
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involved  in  assimilating  new  hires.  As  veterans  train 
newcomers,  this  training  can  reduce  the  veterans' 
productivity  which  will  affect  the  project's  progress. 

[Ref.  2 :p.  102] 

Several  factors  influence  the  project  manager's 
decision  regarding  workforce  size.  Amongst  these  are  the 
scheduled  completion  date  and  the  workforce  stability. 
Concern  over  workforce  stability  leads  project  managers  to 
attempt  to  predict  the  project  employment  time  for 
perspective  employees  before  they  are  hired.  Generally,  the 
"weight  the  managers  give  to  stability  versus  completion 
date  changes  as  the  project  progresses."  [Ref.  2:p.  102] 
This  subsystem  will  be  the  primary  area  in  which 
enhancements  to  the  model  will  be  made.  Development  of  the 
central  staffing  function  necessary  to  model  the  transfer  of 
personnel  between  projects  will  occur  in  this  subsystem. 

2 •  Software  Production  Subsystem 

The  software  production  subsystem  models  the 
development  phase,  to  include  design,  coding,  and  testing. 

It  does  not  include  the  requirements  definition  phase  nor 
does  it  include  the  operation  and  maintenance  phases. 

This  subsystem  models  productivity,  defined  as 
potential  productivity  minus  the  loss  from  faulty  processes. 
Potential  productivity  is  the  maximum  level  of  productivity 
that  can  be  reached  when  a  group  makes  best  use  of  its 
resources.  It  is  dependent  on  the  nature  of  the  task  and 
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the  resources  available  to  the  group.  "Loss  from  faulty 
processes  are  losses  in  productivity  from  things  like 
communication  and  coordination  overhead  and  low  motivation." 
[Ref.  2 :pp.  102-103] 

3 .  Control  Subsystem 

In  all  organizations,  the  decision  makers  make 
decisions  based  on  the  available  information,  which  is  often 
inaccurate.  Factors  such  as  time  lag,  information  flow,  and 
distortion  cause  perceived  conditions  to  be  far  different 
from  those  actually  encountered.  [Ref.  2:p.  103] 

Progress  rate  is  one  example  of  a  variable  in  the 
model  which  is  difficult  to  measure  during  the  project. 
Determination  of  a  quantifiable  way  in  which  to  measure 
progress  is  one  of  the  greatest  roadblocks  to  accurate 
measurement.  Often  when  a  programmer  is  asked  to  provide  an 
estimate  of  the  amount  of  progress,  he  will  divide  the 
amount  of  time  he  has  spent  on  the  project  by  the  amount  of 
time  budgeted.  The  realization  that  his  estimate  is  wrong 
will  occur  only  towards  the  end  of  the  project.  [Ref.  2:p. 
103] 

This  type  of  progress  measurement  causes  status 
reporting  to  be  an  echo  of  original  estimates,  often  grossly 
misstated.  As  the  project  progresses  into  its  final  phases, 
accomplishments  tend  to  become  more  visible  and  project 
members  are  better  able  to  report  how  productive  they  have 
been.  [Ref.  2:p.  103] 
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4 .  Planning  Subsystem 


In  the  planning  subsystem,  initial  project  estimates 
are  made  at  the  beginning  of  the  project  for  various  factors 
such  as  completion  time,  original  staffing  levels,  and  man- 
days  required  to  complete  the  project.  These  estimates  are 
revised  throughout  the  project's  life  based  on  feedback  from 
other  subsystems. 

For  example,  if  a  project  is  perceived  to  be  behind 
schedule,  plans  can  be  made  to  add  more  people,  extend  the 
project's  schedule  or  do  some  of  both.  These  types  of 
decisions  are  motivated  by  variables  that  change  dynamically 
through  the  project's  lifecycle.  One  illustration  of  this 
occurrence  has  to  do  with  staffing  level.  Often,  management 
will  respond  to  a  project  being  delayed  in  its  early  stages 
by  increasing  the  workforce.  However,  as  time  passes  and  it 
becomes  later  in  the  project's  lifecycle,  management  becomes 
more  and  more  reluctant  to  change  the  workforce.  This  is 
due  to  the  realization  that  the  time  doesn't  exist,  prior  to 
the  necessary  completion  date,  to  assimilate  and  train  these 
new  people.  [Ref.  4:p.  1431] 

C.  SUMMARY 

In  this  chapter,  a  brief,  high-level  explanation  of  the 
System  Dynamics  model  of  software  project  management  has 
been  presented.  For  the  interested  reader,  a  more  detailed 
description  of  the  model  can  be  found  in  Reference  4.  The 
explanation  presented  in  this  chapter  provides  a  basis  for 
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This 


understanding  of  the  extension  of  the  model  to  a 
multiproject  environment,  the  purpose  of  this  thesis 
extension  is  described  in  the  next  chapter. 
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III.  EXTENSIONS  TO  MODEL  A  MULTIPROJECT  ENVIRONMENT 


A.  EXISTING  MODEL 

The  System  Dynamics  model  as  described  in  the  previous 
chapter  allows  simulation  of  one  project  at  a  time.  Though 
this  enables  project  managers  and  others  involved  in 
software  development  to  understand  the  dynamics  of  this  one 
project,  it  ignores  the  dynamics  of  situations  involving  two 
or  more  projects.  Software  organizations  are  often,  if  not 
always,  involved  in  the  development  of  more  than  one  project 
or  of  a  project  with  more  than  one  component.  People  are 
transferred  between  projects  or  components  as  well  as  being 
hired  and  fired.  Many  variables  affect  management's 
decisions  regarding  when  and  how  these  workforce  changes 
should  take  place.  Extension  of  the  System  Dynamics  model 
to  enable  the  model  to  demonstrate  the  effects  of  these 
manpower  decisions  in  a  multiproject  environment  is  the 
primary  objective  of  this  thesis. 

This  extension  affected  primarily  the  human  resource 
management  subsystem  as  the  movement  of  people  with  regards 
to  the  workforce  was  the  point  of  interest.  In  order  to 
grasp  the  changes  made,  one  must  first  be  somewhat  familiar 
with  the  subsystem  as  it  existed  prior  to  enhancement. 

Recall  that  the  human  resource  management  subsystem  is  one 
of  four  interrelated  subsystems  making  up  the  System 
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Dynamics  model.  This  relationship  is  pictured  in  Figure  4 
[Ref.  7:p.  8a]. 


Figure  4 .  The  System  Dynamics  Model  of  Software 
Project  Management 


The  human  resource  management  subsystem  models  the 
movement  of  people  into  and  out  of  the  workforce.  It  also 
models  the  training  and  assimilation  of  the  workforce. 
[Ref.  7:p.  102]  Figure  5  illustrates  the  design  of  the 
subsystem  prior  to  its  extension  [Ref.  7:p.  8b].  A  more 
complete  description  of  this  subsystem  and  the  model  as  a 
whole  can  be  found  in  Reference  4 . 
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Figure  5.  The  Human  Resource  Management  Subsystem 


The  schematic  conventions  used  in  Figure  5  are  the 
standard  conventions  used  in  system  dynamics  models. 
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level 


Constants,  whose  values  will  not  change  over  the  course  of 
the  simulation,  are  indicated  by  the  symbol  shown  below: 


\ 


Variables,  as  discussed  in  Chapter  II,  include  levels  and 
rates.  These  are  represented  as  shown  below: 


RATE 


RATE 


The  cloud-like  symbols  represent  sources  and  sinks  which 
indicate  where  resources  come  from  and  go  as  they  flow  into 
and  out  of  levels.  "For  example,  for  a  level  of  workforce 
these  symbols  represent  where  people  come  from  when  hired 
and  where  they  go  when  leaving  the  project."  [Ref.  7:p.  9] 
Referring  back  to  Figure  5,  one  can  see  these  symbols 
used  to  indicate  the  relationships  between  the  variables  in 
the  human  resource  management  subsystem.  For  instance,  the 
source  (the  cloud-like  symbol)  on  the  left  of  the  figure 
represents  people  available  to  be  hired.  They  are  hired  by 
the  organization  at  a  certain  rate  (HIRERT) ,  i.e.,  people 
per  day.  This  rate  is  influenced  by  the  delay  in  hiring 
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(HIREDY)  and  how  many  people  need  to  be  hired  (WFGAP) .  Once 
hired,  these  people  become  part  of  the  newly  hired  workforce 
(WFNEW) .  By  tracing  Figure  5  in  this  manner,  the 
relationship  between  the  variables  in  the  existing  human 
resource  management  subsystem  becomes  evident. 

B.  MODEL  EXTENSIONS 

Three  changes  were  made  to  the  existing  model  to  enable 
simulation  of  a  multiproject  environment.  The  first  and 
second  of  these  did  not  involve  the  human  resource 
management  subsystem  alone  but  rather  affected  the  entire 
model.  The  first  change  was  to  modify  all  applicable 
variables  so  that  they  represented  arrays.  The  addition  of 
arrays  enabled  appropriate  variables  to  be  applied  to  both 
projects  (the  completed  extension  to  the  model  permits 
simulation  of  two  projects  at  the  same  time) .  This 
capability  reduced  greatly  the  need  for  redundant  program 
code . 

The  second  change  involved  inclusion  of  a  variable  which 
would  allow  independent  modelling  of  the  two  projects.  This 
variable,  start  date  (STRTDT) ,  is  aptly  named  in  that  it 
represents  the  time  at  which  each  project  begins 
development.  It  can  be  changed  to  simulate  different 
projects  starting  at  different  times  relative  to  each  other. 
"What  if"  analysis  can  be  performed  by  making  changes  to 
this  variable.  This  analysis  can  help  the  manager  to 


19 


determine  optimum  degrees  of  overlap  necessary  to  attain 
certain  goals,  such  as  minimizing  costs  or  project  duration. 

The  third  change,  the  most  major  one,  was  made  to  the 
human  resource  management  subsystem.  This  change  centered 
on  addition  of  a  centralized  staf f-coupling  sector  to  be 
used  in  simulating  the  transfer  of  people  between  projects. 

A  diagram  of  this  concept  is  shown  in  Figure  6. 

The  change  required  identification  and  introduction  of 
many  variables  to  accurately  model  the  numerous  factors 
involved  in  a  manager's  decision  to  change  his  workforce 
through  intraorganization  transfers.  The  high  level  design 
of  the  model  is  shown  in  Figure  7.  Note  that  this  design 
illustrates  only  those  factors  involved  in  transferring 
workforce  from  project  two  to  project  one.  Transfers 
effected  in  the  other  direction  require  equivalent 
variables.  A  key  to  the  translation  of  the  variable  names 
can  be  found  in  Figure  8;  this  key  is  also  applicable  to  the 
variables  identified  in  Figures  9  and  10. 

C.  DESCRIPTION  OF  MULTIPROJECT  ENVIRONMENT 

As  stated  earlier,  the  major  modification  to  the 
existing  model  was  addition  of  the  changes  necessary  to 
simulate  transfers  between  projects.  The  remainder  of  this 
chapter  will  be  devoted  to  a  description  of  the  environment 
in  which  the  decision  to  use  transferred  workers  is  made  and 
how  these  transfers  are  effected.  To  enhance  clarity  in 
this  discussion,  only  the  situation  in  which  project  one  has 
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Figure  7 


Design  of  the  Multipro j ec-*:  Staff-Coupling 
Sector 
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VAR I  ABLE  KEY 


A3 1 MET ~A5SI M I LAT I  ON  FATE  OF  MEW  EMPLOYEES  (PEOPLE/DAY) 

ASriTRF-ASS  I II I  l.AT  I  CM  DELAY  OF  TRANSFERRED  PEOPLE  (DAYS) 

C E I LHP=CE IH NO  ON  HIRING  FOP  PROJECT  1  (PEOPLE) 

HIREF:T=HIF:ING  RATE  (FEOF'LE/DAY ' 

MNHRXW— MOST  NEW  HIREES  PEP  EXPERIENCED  STAFF  (MEN/MEN) 

MXDT 1 F —MAX  I  MUM  WORT  FORCE  THAT  CAN  E<E  FORCED  TO  TRANSFER'  FROM  PROJECTS 
TO  PROJECT  1  (PEOPLE) 

PROJECT  PRIOPITY=DETEPMINhTION  OF  WHETHER  ONE  PROJECT  HAS  PRIORITY  OVER 
ANOTHER 

DUITRT=E>:PERIENi;eD  PEOPLE  OUIT  PATE  (PEOPLE/DAY) 

RLSDT 1 =WORT  FORCE  TO  BE  RELEASED  AFTER  PROJECT  D’S  COMPLETION  THAT  PROJECT 
1  CAN  RELY  ON  AND  AFFORD  TO  WAIT  FOR  (FEOF'LE 
TOTUF  =  TOTAL  WORT  FORCE  LEVEL  (PEOPLE) 

TRANSFER  DELAY-DELAY  REQUIRED  UNTIL  TRANSFER  IS  AFFECTED  (DAYS) 
TFNFWr=TRAMSFERF:ED  PEOPLE  PROM  PROJECT  0  TO  PROJECT  1  (PEOPLE) 
TPWFAR=TRANSFERPEP  WORKFORCE  ASSIMILATION  PATE  INTO  FPOJECT  l’S 
WORKFORCE  'PEOPLE /DAY ) 

WCWF  =  WILLINGNESS  TO  CHANGE  THE  WORKFORCE 

WFOT 1 1 =MAX I MUM  WORKFORCE  WE  CAN  FORCE  TRANSFER  FROM  PROJECT  0  TO  PROJECT  1 
AS  DETERMINED  BY  MANAGEMENT  POLICY  (PEOPLE) 

WF0T10=W0RF.F0FCE  WE  CAN  TRANSFER  FROM  PROJECT  0  TO  PROJECT  1  WHEN  WE 

TATE  INTO  CONSIDERATION  WILLINGNESS  TO  PERLENISH/DELAY  PROJECTS' 

WFl'T  1  F=WORI  FOFCE  THAT  WILL  BE  FORCIBLY  TRANSFERRED  FROM  PROJECT  0  TO 
PROJECT  1  ( REQFLE ’ 

WF;:TIT=T0TAL  WORT  FORCE  THAT  WILL  BE  TRANSFERRED  FROM  PROJECT  2  TO 
PROJECT  I  1  PEOPLE i 

WT1' T 1  W--WOf- 1  FORCE  TRANSFERRED  FROM  PROJECT  0  TO  PROJECT  1  WILLINGLY  'PEOPLE 
WFAPVF=WORI  FORCE  A^-'ROVEC  TO  HIRE  (PEOPLE  ’ 

WFAt-'G-  WOF'T  FOR’  L  ARRANGED  FOR.  IT  EQUALS  WOPF FORCE  +  WORKFORCE  TO  BE 
TRANSFERRED  TO  PROJECT  1  MINUS  WORKFORCE  TO  BE  TRANSFERRED  OUT 
WFEXES-WCF!  FORCE  EXCESS.  IT  ECUALS  WORT. FORCE  WILLING  TO  TRANSFER  To  OTHER 
PROJECT  (PEOPLE' 

WFEXP=  EXPERIENCED  WORKFORCE  (PEOPLE) 

Wi'Gf ,p=  WORKFORCE  THAT  NEEDS  TO  BE  TRANSFERRED  FROM  OTHER  PROJECT  (PEOPLE' 
WF IMDC  =  INDICATED  WORKFORCE  (PEOPLE) 

WFNDHR=WOP T'FOPC E  NEEDED  IF  PEOPLE  WILL  BE  HIRED  (PEOPLE) 

WFNDTR -WORK FORCE  LEVEL  NEEDED  ASSUMING  TRANSFERS  (PEOPLE) 

WFNEW1 =NEW  WOPFOFCE  (PEOPLE’ 

WFOUT=  WORT FOFCE  DEFINITELY  NEEDED  TO  BE  HIRED  FROM  OUTSIDE  (PEOPLE) 

WFSMF:=  WORT  FORCE  SOUGHT  TO  HIRE  (PEOPLE) 

WNDT!F=WORT FORCE  NEEDED  TO  EE  TRANSFERRED  BY  FORCE  FROM  PROJECT  0  TO 
PROJECT  1  i PEOPLE i 


Figure  8.  Variable  Key 
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Figure  10.  Decomposition  of  WF2T1F 


priority  and  therefore  receives  transfers  from  project  two 
will  be  described. 

First,  the  manager  will  determine  the  total  number  of 
workers  needed  (WFINDC)  by  ascertaining  the  scope  of  the 
project  (man-days  required  to  complete  the  project  as  it  is 
estimated).  He'll  then  compare  this  number  to  the  total 
workforce  (TOTWF)  on  hand  to  determine  the  gap  in  the 
workforce  (WFGAP) .  Since  transferred  workers  tend  to  be 
more  productive  and  require  less  assimilation  time  than 
their  newly  hired  counterparts,  most  managers  would  prefer 
to  meet  the  gap  between  what  is  needed  and  what  is  on  hand 
through  transfer.  This  determination  of  the  need  for 
transfers  is  a  continuing  process  throughout  the  life  of  the 
project  as  the  manager  continually  updates  his  estimates  of 
project  size  and  how  much  of  the  project  is  completed. 
Returning  to  Figure  7,  one  can  see  that  it  is  through  this 
transferring  process  that  the  two  projects  interact.  Once 
the  manager  has  determined  the  amount  of  workforce  that  he 
needs  to  have  transferred  to  his  project,  there  are  two  ways 
in  which  these  transfers  can  be  affected. 

First,  these  transferees  may  be  people  who  are 
transferred  willingly  (WF2T1W) ,  meaning  management  in 
project  two  acknowledges  that  they  have  more  than  enough 
people  to  get  the  job  done.  These  "willing"  transfers  are, 
in  fact,  recognized  as  excess  workforce  (WFEXES)  as  shown  in 
Figure  7.  The  workforce  which  is  in  excess  will  be 
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willingly  transferred  but  this  may  not  meet  the  needs  of 
project  one.  The  manager  then  realizes  the  number  of 
individuals  he  needs  to  transfer  by  force  (WN2T1F) .  This 
"forced"  transferring  will  occur  when  the  overall 
organizational  goals  can  best  be  met  through  these 
transfers. 

Figure  10  presents  the  factors  involved  in  determining 
what  amount  of  the  workforce  will  be  transferred  by  force 
(WF2T1F) .  Two  factors  influence  this  determination — these 
factors  are  management  policy  and  willingness  to  replenish 
or  delay  the  other  project. 

The  first  item  (WF2T11)  which  influences  forced 
transfers  is  management  policy.  This  policy  is,  in  turn, 
determined  with  regard  to  two  considerations.  One 
consideration  is  the  willingness  of  project  one  to  force 
transfers  from  project  two.  In  the  early  phases  of  project 
development,  project  one  will  be  more  apt  to  hire  from  the 
outside  and  not  disrupt  the  other  project  through  forced 
transfer.  This  is  due  to  reluctance  to  force  transfers  from 
the  other  project  when  it  is  building  its  "core"  team  (i.e., 
in  the  early  stages  of  the  project) .  The  second 
consideration  influencing  management  policy  is  attention 
given  to  the  cumulative  number  of  "recent"  transfers  as  the 
more  recently  transfers  have  occurred  in  noticeable  numbers 
the  less  apt  the  losing  manager  is  to  give  up  yet  more 
people. 
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The  other  item  (WF2T12)  influencing  forced  transfers  is 
regard  for  the  willingness  to  replenish  or  delay  the  other 
project.  The  ability  to  replenish  project  two  affects  the 
number  of  forced  transfers  which  take  place.  If  the 
organization  has  a  workforce  ceiling  and  it  is  close  to  that 
ceiling,  there  will  be  more  reluctance  to  replenish  project 
two  which  will  in  turn  lead  to  fewer  forced  transfers.  The 
amount  of  delay  which  can  be  afforded  also  affects  the 
number  of  transfers  which  take  place.  This  delay  is  a 
function  of  the  maximum  tolerable  completion  date  of  the 
project — the  "drop  dead"  time  for  completion.  The  minimum 
tolerable  workforce  with  which  project  two  can  continue 
development  is  based  on  this  delay.  Forced  transfers  will 
not  drive  the  workforce  below  this  number. 

The  amount  of  workforce  which  will  be  transferred 
willingly  (WF2T1W)  combined  with  the  number  that  can  be 
transferred  by  force  (WF2T1F)  constitute  the  total  workforce 
that  will  be  transferred  from  project  two  to  project  one 
(WF2T1T) .  This  relationship  is  shown  in  Figure  10.  The 
number  of  individuals  who  make  up  the  to-be-transferred 
force  combined  with  the  original  workforce  are  then 
considered  to  be  "arranged  for"  (WFARG)  as  shown  in  Figure 
9.  Prior  to  the  transfer  being  achieved,  however,  a 
transfer  delay  is  incurred  as  preparation  is  made  for  the 
transfer  both  by  project  two  and  by  the  individual.  Once 
the  transfer  is  complete  a  period  of  assimilation  ensues. 
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Though  individuals  transferred  (TRNFWF)  require  some 
assimilation  time  (TRWFAR) ,  their  rate  of  assimilation  into 
the  gaining  project  is  less  than  that  for  newly  hired 
workers.  This  is  attributable  to  their  understanding  of  the 
organizational  environment  and  their  experience  with  the 
organization's  policies  and  standards.  Additionally,  if  the 
two  projects  are  components  of  a  larger  project,  the 
transferred  workforce  is  at  least  somewhat  familiar  with 
that  overall  project — a  familiarity  which  contributes  to 
their  faster  assimilation  into  the  workforce.  As  members  of 
the  transferred  workforce  are  assimilated  into  the  new 
project,  they  become  part  of  the  experienced  workforce 
(WFEXP) . 

Note  that  if  two  projects  are  running  in  parallel, 
transfers  will  occur  only  in  the  direction  of  the  project 
which  has  higher  priority  (PROJECT  PRIORITY)  until  that 
project  completes.  This  priority  status  may  be  exogenously 
determined  by  organizational  management  as,  for  instance,  a 
result  of  contract  requirements.  In  the  situation  being 
described  in  this  chapter,  project  one  has  been  exogenously 
determined  to  have  priority.  Also  possible  is  determination 
of  a  project's  priority  based  on  its  proximity  to  completion 
relative  to  the  other  project.  It  would  be  foolish  to 
transfer  people  out  of  a  project  which,  due  to  either  of  the 
reasons  mentioned  above,  had  been  designated  as  having  high 
priority. 
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Having  determined  the  workforce  arranged  for,  the 
manager  must  once  again  appraise  his  workforce  situation  and 
determine  if  he  still  needs  to  hire.  He  will  do  this  by 
comparing  the  workforce  he  needs  (WFINDC)  to  the  workforce 
to  which  he  has  access  (WFARG) .  The  difference  between 
these  two  is  the  gap  which  the  manager  must  attempt  to  close 
by  hiring  (WFNDHR) .  Figure  9  shows  the  relationships 
between  the  variables  which  influence  the  acquisition  of  the 
entire  workforce,  both  through  transfer  and  through  hiring. 
Though  the  manager  may,  as  far  as  the  numbers  are  concerned, 
need  to  hire  a  certain  number  of  workers,  other 
considerations  come  into  play.  The  willingness  of 
management  to  hire  new  workers  (WCWF)  will  affect  the  number 
actually  sought  tc  be  hired  (WFSHR) .  Reluctance  to  hire  new 
workers  (WFNEW1)  may  be  due  to  the  nearness  of  completion  of 
the  project — a  manager  will  be  less  willing  to  hire  a  new 
team  member  the  closer  the  project  gets  to  completion  as 
there  may  not  be  time  to  assimilate  that  member.  Another 
consideration  managers  take  into  account  is  the  ratio 
between  new  and  experienced  workers  (MNHPXW) .  The 
productivity  of  experienced  workers  (WFEXP)  will  decline  as 
they  take  the  time  and  effort  to  train  and  socially 
assimilate  their  new  workers.  Aware  of  this  phenomenon, 
managers  will  limit  this  ratio  and  will  hire  only  in  numbers 
compatible  with  their  productivity  needs. 
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Having  calculated  the  number  of  workers  sought  to  hire, 
the  manager  will  once  again  look  at  the  other  project  for  a 
possible  source  of  employees.  He  makes  an  informed  decision 
regarding  the  number  of  individuals  to  be  released  upon  the 
other  project's  completion  on  which  he  can  rely  and  for 
which  he  can  afford  to  wait  (RLS2T1) .  Since  these 
individuals  will  be  released  upon  completion  of  the  project, 
the  management  policy  (WF2T11)  and  willingness  to  replenish 
or  delay  (WF2T12)  factors  which  affected  transfer 
considerations  will  not  come  into  play  here. 

This  number  (RLS2T1)  subtracted  from  the  workforce 
sought  to  hire  (WFSHR)  gives  the  manager  a  final  figure  of 
the  workforce  needed  to  be  acquired  by  hiring  (WFOUT) . 

Before  these  people  are  actually  hired,  however,  the  manager 
needs  to  ensure  he  is  following  organizational  policy  with 
regard  to  any  ceiling  on  the  workforce  (CEILHR) .  Regardless 
of  the  number  of  individuals  needed,  the  organizational 
ceiling  and  how  that  ceiling  will  be  allocated  amongst 
projects  will  be  the  final  determinants  of  how  many  can  be 
hired  (WFAPVH) .  If  the  manager  finds  he  is  unable  to  get 
the  people  he  needs,  he  may  need  to  work  the  people  he  has 
harder  or  extend  the  schedule,  or  both. 

Returning  to  Figure  7,  one  can  see  that  the  workforce 
which  has  been  approved  to  hire  (WFAPVH)  will  increase  the 
number  of  employees  in  the  new  workforce  (WFNEW1)  as  they 
are  hired  (HIRERT) .  This  number  in  turn  increases  the  total 
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workforce  (TOTWF)  of  that  project.  Once  again,  and 
throughout  the  life  of  the  project,  the  manager  will  compare 
this  figure  to  what  he  needs  (WFINDC)  and  the  cycle  of 
filling  the  workforce  gap  will  begin  anew.  It  is  this  sort 
of  cause-and-ef feet  chain  which  makes  the  system  dynamics 
approach  so  appropriate  for  the  software  project  management 
world,  especially  that  of  multiproject  organizations. 

The  changes  described  above  were  incorporated  into  the 
existing  System  Dynamics  model  of  software  project 
management.  Addition  of  the  staff-coupling  sector,  the 
start  date  variable  and  arrays  enabled  modelling  of  a 
multiproject  environment.  Simulations  were  run  with  this 
new  model  in  an  attempt  to  replicate  changes  managers  might 
make  or  contemplate  in  their  management  policies.  The 
results  of  these  simulations  are  presented  in  Chapter  IV. 
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IV.  EXPERIMENT  RESULTS 


A.  EXPERIMENTAL  ENVIRONMENT 

The  System  Dynamics  model  of  software  project  management 
was  written  in  Dynamo,  a  computer  simulation  language  which 
is  described  in  Chapter  II.  The  variables  necessary  to 
model  a  multiproject  environment,  identified  in  Chapter  III, 
were  incorporated  into  this  Dynamo  program.  This  program, 
run  on  a  personal  computer,  provided  the  vehicle  for  the 
conduct  of  the  experiments  presented  in  this  chapter. 

B.  DESCRIPTION  OF  EXPERIMENTS 

After  implementation  of  the  changes  made  to  the  System 
Dynamics  model  of  software  project  management,  several 
experiments  were  conducted  by  running  simulations.  These 
experiments  were  conducted  using  the  characteristics  of  an 
actual  software  project.  This  project,  NASA's  DE-A  project, 
was  conducted  at  Goddard  Space  Flight  Center.  The 
requirements  for  the  project  were  to  design,  implement,  and 
test  a  software  system  for  processing  telemetry  data  and 
providing  attitude  determination  and  control  for  the  DE-A 
satellite.  The  project's  size  was  24,000  delivered  source 
instructions.  This  size  was  initially  underestimated  by  35 
percent.  The  initial  estimates  of  cost  and  schedule  were 
1100  man-days  and  320  days,  respectively.  The  actual 
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results  were  a  cost  of  2200  man-days  and  a  schedule  of  380 
days.  [Ref.  4:p.  1432] 

In  the  multi-project  environment  present  in  the  extended 
model,  these  statistics  were  given  to  both  projects.  In 
most  of  the  simulations  the  nominal  ceiling  on  the  total 
workforce  (NCLTWF)  was  set  to  a  default  value  of  30 
(exceptions  are  noted  in  the  text) .  This  condition  enabled 
simulations  to  be  run  which  showed  the  effect  of  manpower 
constraints.  Results  of  a  single  project  restricted  in  this 
manner  are  a  cost  of  1909.5  days  and  a  schedule  of  398  days. 
In  this  case  of  a  single  project,  the  nominal  ceiling  on  the 
total  workforce  is  15  (one-half  that  for  the  two-project 
simulations) .  This  constraint  was  not  in  effect  in  the 
actual  DE-A  project.  Its  addition  does  not  affect  the  fact 
that  the  experiments  were  run  with  two  identical  projects 
both  of  which  were  in  distress  as  they  were  initially 
underestimated.  The  results  of  the  experiments  will  be 
presented  in  this  chapter.  Prior  to  this,  however,  an 
explanation  of  how  the  experiments  were  structured  is 
necessary. 

Three  sets  of  experiments  were  conducted.  All  three 
provide  a  glimpse  at  the  capability  for  sensitivity  analysis 
that  this  model  provides  the  software  project  manager.  The 
first  of  these  involved  running  simulations  to  determine  the 
optimal  degree  of  overlap  to  minimize  cost  in  seven 
different  situations.  The  second  set  of  experiments 
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consisted  of  simulations  run  based  on  an  optima]  degree  of 
overlap  when  the  project  starting  first  had  priority.  In 
this  case  results  from  13  simulations,  each  with  a  different 
independent  variable,  are  presented.  The  third  set  of 
experiments  consisted  of  simulations  run  based  on  an  optimal 
degree  of  overlap  when  the  project  starting  last  had 
priority.  Again,  results  from  13  simulations,  each  with  a 
different  independent  variable,  are  presented.  A  more 
detailed  description  of  each  experiment  precedes  the 
presentation  of  the  results  peculiar  to  that  experiment. 

C.  EXPERIMENT  SET  ONE 

In  the  first  set  of  experiments,  simulations  were  run  to 
determine  the  optimal  degree  of  overlap  between  two  projects 
necessary  to  minimize  costs  of  the  combined  projects.  In 
the  first  five  cases,  the  priority  was  set  dynamically 
(PRTYSW  =  0) — that  is,  the  project  whose  indicated 
completion  date  is  farthest  from  its  scheduled  completion 
date  would  be  the  project  which  would  receive  transfers  from 
the  other  as  it  is  perceived  to  be  in  greater  distress.  As 
time  progresses  the  project  having  priority  will  change  as 
one  project  "gains"  on  the  other  due  to  the  advantage  of 
receiving  transfers. 

1 .  Baseline 

Figure  11  shows  the  results  of  tests  run  to 
determine  the  optimum  overlap  required  to  minimize  costs 
when  dynamic  priority  is  used.  In  this  simulation,  as  in 
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all  others  in  this  experiment  set  (with  the  exception  of  the 
two  simulations  in  which  workforce  ceiling  was  changed) ,  the 
nominal  ceiling  on  the  workforce  has  the  value  of  30.  Since 
Figure  ll  is  identical  in  format  to  the  others  in  this 
section,  a  brief  explanation  of  it  is  appropriate. 


Figure  11.  Overlap  Results — Baseline 


There  are  four  lines  of  results  shown  on  this 
figure.  The  first,  "INDEP,"  indicates  the  combined  cost  of 
two  projects  run  in  parallel  with  no  interaction;  they  are, 
in  other  words,  independent  of  each  other.  No  transfers 
occur  between  projects.  This  line  is  given  as  a  point  of 
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comparison  between  independent  projects  and  projects 
developed  in  a  multiproject  environment  in  which  human 
resources  are  shared. 

The  second  line,  ''PR0J1,''  indicates  the  cost  for 
project  one  at  each  point  of  overlap.  Note  that  for  the 
five  simulations  run  with  dynamic  priority  (this  and  the 
next  four) ,  project  one  was  always  the  project  to  start 
last.  For  instance,  the  number  20  on  the  X-axis  indicates 
that  project  one  started  at  time  20  and  project  two  started 
at  time  zero.  Only  when  the  schedule  overlap  is  zero  do  the 
projects  start  together. 

The  third  line,  "PR0J2,"  indicates  the  cost  of 
project  two  at  each  degree  of  overlap.  Recall  that  project 
two  is  always  the  project  to  start  first. 

The  last  line,  ''TOTAL,”  indicates  the  combined  cost 
of  both  projects  for  each  degree  of  overlap.  This  line 
provides  the  major  point  of  interest  as  a  manager  trying  to 
minimize  overall  costs  would  focus  on  this  information.  It 
is  important  to  recognize  that  determination  of  which 
project  starts  first  (in  this  case,  project  two)  does  not 
skew  the  results  when  the  priority  is  dynamically  set,  as  it 
is  in  five  of  these  experiments.  If  project  one  had  been 
chosen  to  start  first,  its  costs  would  mirror  those  of 
project  two  in  the  current  results  and  vice-versa.  The 
total  costs  would  remain  unchanged. 
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The  final  area  of  attention  with  regard  to  Figure  11 
is  the  choice  of  400  as  the  stopping  point  for  the 
simulations.  The  project  starting  first  will  complete  at 
time  398,  the  same  time  as  if  it  were  running  in  a  single 
project  environment.  This  is  because  it  cannot  receive 
transfers  from  a  project  which  hasn't  started  yet.  It  would 
appear,  then,  that  the  simulations  run  with  one  project 
starting  at  time  400  would  be  in  fact  nothing  more  than  the 
simulation  of  two  independent  projects  as  the  projects  seem 
to  have  no  chance  to  overlap.  In  reality,  however,  even 
though  one  project  completes  at  time  398,  there  is  still 
workforce  available  to  be  transferred  to  the  other  project 
as  it  begins  at  time  400.  This  is  due  to  the  fact  that  when 
a  project  "ends"  there  are  still  things  to  be  taken  care  of 
to  "wrap"  that  project  up.  Individuals  still  on  hand  during 
this  time  are  available  for  transfer  to  the  other  project. 
The  results  of  this  experiment  show  that  the  optimal  degree 
of  overlap  occurs  when  the  projects  start  at  the  same  time. 
This  is  shown  in  the  summary  results  in  the  appendix. 

2 •  Transfer  Productivity 

In  the  second  simulation  of  this  experiment  set,  the 
variables  changed  were  the  variables  which  affect  the 
nominal  productivity  of  experienced  people  (NPPRWT)  and 
transfer  delay  (TRNSDY) .  By  increasing  NPPRWT  (from  zero  to 
.5)  and  decreasing  TRNSDY  (from  ten  to  five),  the  scene  set 
is  one  in  which  transferred  people  are  more  productive.  As 
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stated  earlier,  the  priority  is  set  dynamically  in  this 
simulation.  The  results  of  the  tests  run  to  determine  the 
optimum  degree  of  overlap  to  minimize  cost  are  shown  in 
Figure  12.  The  summary  of  the  results  is  contained  in  the 
appendix.  They  show  that  the  optimal  degree  of  overlap 
occurs  when  the  projects  start  at  the  same  time. 


3 .  Workforce  Ceiling 

In  this  set  of  simulations,  the  ceiling  on  the 
organizational  workforce  was  decreased  from  the  default 
value  of  30  to  20.  The  priority  is,  once  again,  determined 


39 


dynamically.  The  results  of  the  efforts  to  determine  the 
optimum  degree  of  overlap  to  minimize  costs  under  these 
conditions  are  shown  in  Figure  13.  The  summary  results  are 
presented  in  the  appendix.  They  show  that  the  optimal 
overlap  occurs  under  these  conditions  when  one  project 
starts  400  days  after  the  other. 


Figure  13.  Overlap  Results — Workforce  Ceiling 


4 .  Workforce  Ceiling  and  Allocation 

In  this  scenario,  the  conditions  were  the  same  as  in 
the  third,  above,  with  the  addition  of  one  other  change. 

The  allocation  of  the  workforce  ceiling  was  set  such  that 


40 


the  project  with  priority  could  employ  up  to  the  ceiling  on 
workforce  for  the  entire  organization,  leaving  the  other 
project  with  no  pool  from  which  to  acquire  additional 
workforce  (P0LCY1  =  0) .  Normally,  the  ceiling  is  allocated 
on  a  50:50  basis,  with  each  project  allowed  to  employ  up  to 
one-half  the  workforce  ceiling  (P0LCY1  =  1) .  Results  of 
cost  minimization  simulation  runs  are  shown  in  Figure  14; 
summary  results  are  shown  in  the  appendix.  Starting  one 
project  160  days  after  the  other  provides  the  optimal  degree 
of  overlap. 


Figure  14.  Overlap  Results — Workforce  Ceiling  and 
Allocation 
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5.  Hiring  and  Transferring  Aggressiveness 


In  this  set  of  simulations,  the  variables  affecting 
the  aggressiveness  in  hiring  (TMPRMR)  and  receiving 
transfers  (TAGRSV)  were  changed  to  model  a  situation  in 
which  the  manager  is  more  aggressive  in  these  areas.  TMPRMR 
was  decreased  from  50  to  25  and  TAGRSV  was  decreased  from 
one  to  . 5 .  Note  that  a  decrease  in  these  variables  caused 
an  increase  in  aggressiveness.  This  is  the  last  set  of 
simulations  in  which  the  priority  is  dynamically  set. 

Figure  15  shows  the  results  of  the  simulation  runs  for 
optimizing  overlap  in  regard  to  minimizing  cost.  The 
appendix  provides  a  summary  of  these  results.  In  this 
setting  the  optimal  degree  of  overlap  occurs  when  one 
project  starts  300  days  after  the  other. 

6.  Project  Starting  First  Has  Priority 

In  this  set  of  simulations,  as  in  the  next,  the 
project  priority  is  set  statically  (PRTYSW  =  1) .  That 
project  which  will  have  priority  is  determined  at  the 
beginning  of  the  simulation  by  the  manager  and  remains 
unchanged  throughout.  In  this  and  the  next  set  of 
simulations,  project  one  has  priority  (TRPY11  =  1) .  In  this 
set,  project  one  is  also  the  project  which  starts  first; 
therefore,  when  the  X-axis  is  labelled,  for  instance,  100, 
this  means  that  project  one  started  at  time  zero  and  project 
two  started  at  time  100.  Figure  16  shows  the  results  of 
this  experiment  in  which  the  optimal  degree  of  overlap  is 
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SCHEDULE  0VS3LAP  (DAYS} 

O  t  NDEP  o  PRQJ1  A  PRQJ2  X  TOTAL 


Figure  15.  Overlap  Results — Hiring  and  Transferring 
Aggressiveness 


reached  when  project  one  starts  120  days  before  project  two. 
A  summary  of  these  results  is  provided  in  the  appendix. 

These  results  will  be  used  in  determining  a  starting  point 
for  the  second  set  of  experiments. 

7 .  Project  Starting  Last  Has  Priority 

In  this  set,  project  one  also  has  priority  but  in 
contrast  to  the  sixth  set  of  simulations,  above,  it  is  the 
project  which  starts  last;  therefore,  when  the  X-axis  is 
labelled,  for  instance,  100,  this  means  that  project  one 
started  at  time  100  and  project  two  started  at  time  zero. 
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SCHEDULE  OVERLAP  (DAYS) 

□  INDEP  ©  PR0J1  A  PROJ2  X  TOTAL 

Figure  16.  Overlap  Results— Project  Starting  First  Has 
Priority 

Figure  17  shows  the  results  of  this  experiment  in  which  the 
optimal  degree  of  overlap  occurs  when  project  one  starts  100 
days  after  project  two.  The  appendix  provides  a  summary  of 
the  results.  These  results  will  be  used  in  determining  a 
starting  point  for  the  third  set  of  experiments. 

8 .  Summary 

Figure  18  provides  a  graph  showing  the  different 
optimum  degrees  of  overlap  with  which  to  minimize  cost  for 
each  simulation  in  experiment  set  one.  The  results  attained 
in  this  experiment  set  all  provide  points  for  further 
analysis.  To  provide  the  reader  with  an  understanding  of 
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SCHEDULE  OVERLAP  (DAYS) 

□  INDEP  o  PRQJ1  A  PKU2  X  TOTAL 

Figure  17.  Overlap  Results — Project  Starting  Last  Has 
Priority 

the  factors  that  may  lead  to  these  results,  a  short  analysis 
of  two  of  the  more  extreme  results  will  be  presented  here. 

The  first  simulation  to  be  discussed  is  simulation 
three  in  which  the  nominal  ceiling  on  the  total  workforce 
was  reduced  from  30  to  20.  In  this  simulation,  costs  were 
minimized  when  one  project  started  400  days  after  the  other. 
The  effects  of  hiring  and  transferring  people  may  be  the 
reason  for  this.  For  instance,  when  two  projects  run  at 
approximately  the  same  time  as  is  the  case  when,  say, 
project  one  starts  60  days  after  project  two,  transferring 
of  personnel  does  not  occur  until  relatively  late  in  the 
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Figure  18.  Graphic  Results  of  Experiment  Set  One 

projects  as  neither  can  afford  to  give  them  up  earlier. 

This  coupled  with  the  decreased  ability  to  hire  as  a  result 
of  the  decrease  in  the  workforce  ceiling  leads  to  less 
overall  productivity.  The  change  in  productivity  happens 
since  transferred  workers  are  assimilated  later  in  the 
projects  and  are  not  able  to  ”pull  their  load”  for  very 
long.  Additionally,  new  workers  are  fewer  in  number  than 
when  the  workforce  ceiling  is  higher.  When  productivity  is 
decreased,  costs  increase.  In  the  case  in  which  the 
projects  start  very  far  apart,  as  in  this  simulation  in 
which  one  project  starts  400  days  after  the  other,  the 


project  starting  later  is  able  to  get  transfers  almost 
immediately  since  the  other  project  has  completed.  The 
reduced  number  of  people  it  can  hire  does  not  affect  it  in 
an  adverse  way  because  the  transferred  people  contribute 
their  share  to  the  accomplishment  of  the  workload  throughout 
the  project's  lifecycle. 

The  other  simulation  of  interest  is  the  fifth 
simulation  in  which  the  aggressiveness  of  the  manager  in 
hiring  and  transferring  is  increased.  The  minimal  cost  is 
achieved  when  one  project  starts  300  days  after  the  other. 
This  is  also  caused  by  hiring  and  transferring.  When  the 
projects  are  running  at  approximately  the  same  time, 
transfers  occur  throughout  the  life  of  both  projects.  When 
one  project  ends,  the  other  aggressively  seeks  transfers 
even  though  it  may  be  near  completion.  This  decreases 
productivity  and  increases  cost.  When  the  projects  start 
further  apart,  though,  transfers  occur  earlier  in  the  life 
of  the  second  project  allowing  earlier  realization  of  the 
benefits  in  productivity  of  the  transferred  workers  and  thus 
reducing  cost. 

This  brief  analysis  of  these  two  simulations 
provides  insight  into  some  of  the  factors  affecting  software 
project  management  in  a  multiproject  environment.  A  more 
detailed  analysis  of  these  as  well  as  the  other  simulations 
in  this  experiment  set  should  increase  the  understanding  of 
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the  complex  and  interdependent  variables  affecting  cost 
minimization  under  different  situations. 

D.  EXPERIMENT  SET  TWO 

The  second  set  of  experiments  involved  simulations  run 
when  the  project  starting  first  had  priority.  As 
illustrated  in  Figure  16,  costs  were  minimized  when  the 
project  having  priority,  project  one,  began  120  days  before 
the  project  without  priority.  In  each  of  the  follow-on 
simulations  run  under  this  scenario,  the  start  date  of  the 
second  project  was  set  to  120.  Other  parameters  of  note 
which  remained  unchanged  throughout  this  scenario,  unless 
otherwise  indicated,  include  the  project  priority  as  already 
discussed,  and  the  workforce  ceiling  allocation  policy.  The 
default  value  for  this  parameter  was  such  that  the  workforce 
ceiling  was  allocated  on  a  50:50  basis  between  projects. 
Also,  the  nominal  ceiling  on  the  total  workforce  was  set  to 
30  thus  allowing  no  more  than  30  employees  in  the  entire 
organization.  Unlike  the  previous  set  of  experiments  these 
were  not  conducted  to  determine  the  optimum  overlap  to 
minimize  cost.  Rather,  as  stated  above,  the  overlap  was  set 
and  other  variables  were  manipulated  in  order  to  provide 
points  of  comparison  between  different  conditions  in  an 
optimum  overlap  situation.  These  results  are  graphically 
presented  in  Figure  19.  Table  1  provides  a  summary  of  the 
simulations  run  in  this  scenario.  The  names  of  each 
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Figure  19.  Graphic  Results  of  Experiment  Set  Two 

independent  variable  are  explained  in  the  section  pertaining 
to  that  simulation.  The  reader  will  note  that  several  of 
the  variables  manipulated  in  the  first  set  of  experiments 
were  also  changed  in  this  and  the  third  set  of  experiments. 

1 .  Baseline 

The  first  simulation  presented  is  the  "baseline" 
simulation  in  which  project  one  has  higher  priority,  project 
one  started  120  days  before  project  two,  the  workforce 
ceiling  allocation  policy  is  50:50,  and  the  ceiling  on  the 
total  workforce  is  30.  This  simulation  provides  a  basis  for 
comparisons  with  others  within  this  experiment  sev. 
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TABLE  1 

RESULTS  FROM  EXPERIMENT  SET  TWO  SIMULATIONS 


■ 

Independent 

Cost 

Schedule 

Transfers 

Transfers 

■ 

Variable 

(Man-days) 

(Days) 

2  to  1 

1  to  2 

1 

BASELINE 

3690.93 

519.50 

-8.84 

8.84 

2 

TRPY11 

3804.75 

447.00 

2.34 

-2.34 

3 

PRTYSW 

3929.72 

468.00 

-16.21 

16.21 

4 

P0LCY1 

4343.44 

514.50 

-16.89 

16.89 

5 

TAGRSV 

3690.93 

519.50 

.84 

- 

8.84 

6 

T2T1F2 

T1T2F2 

3690.93 

519.50 

-8.84 

8.84 

1 

TB2T11 

TB1T21 

3690.26 

519.50 

-8.84 

8.84 

8 

TC2T11 

TC1T21 

3659.45 

540.50 

-8.24 

8.24 

9 

FORGETa 

3670.27 

541.00 

-8.33 

8.33 

10 

FORGETb 

3742.06 

501.50 

-9.34 

9.34 

11 

TMP1R2 

TMP1R1 

3690.03 

519.50 

-8.84 

8.84 

12 

TWRL2Tla 

TWRLlT2a 

3770.12 

618.50 

-12.85 

12.85 

13 

TWRL2Tlb 

TWRLlT2b 

3733.06 

498.00 

6.34 

-6.34 

Figure  20  provides  a  statistical  report  on  the 
results  of  this  simulation.  The  statistical  reports  for  all 
simulations  to  be  presented  in  this  and  the  next  section 
will  be  identical  in  format  to  that  presented  in  this 
figure.  These  reports  are,  for  the  most  part,  self- 
explanatory.  Note  that  statistics,  including  total  effort, 
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PROJECT  STATISTICS: 

COMPLETION  TIME  ONE 

374.50 

PORTION  OF 
TOTAL  EFFORT 

DAYS 

TOTAL  EFFORT  ONE  1 

,863.02 

MAN-DAYS 

QA  EFFORT  ONE 

457.20 

MAN-DAYS 

.25 

DEVELOP  EFFORT  ONE 

863.15 

MAN-DAYS 

.46 

REWORK  EFFORT  ONE 

261.58 

MAN-DAYS 

.14 

TESTING  EFFORT  ONE 

232.22 

MAN-DAYS 

.12 

TRAINING  EFFORT  ONE 

48.86 

MAN-DAYS 

.03 

OVERALL-PRODUCTIVITY  ONE 

13.10 

TASKS/MAN-DAY 

COMPLETION  TIME  TWO 

519.50 

DAYS 

TOTAL  EFFORT  TWO  1 

,827.91 

MAN-DAYS 

QA  EFFORT  TWO 

411.77 

MAN-DAYS 

.23 

DEVELOP  EFFORT  TWO 

881.43 

MAN-DAYS 

.48 

REWORK  EFFORT  TWO 

265.20 

MAN-DAYS 

.  15 

TESTING  EFFORT  TWO 

245.93 

MAN-DAYS 

.  13 

TRAINING  EFFORT  TWO 

23.58 

MAN-DAYS 

.01 

OVERALL-PRODUCTIVITY  TWO 

13.35 

TASKS/MAN-DAY 

NET  TRANSFERS  2  TO  1 

-  8.84 

MEN 

NET  TRANSFERS  1  TO  2 

8.84 

MEN 

TOTAL  EFFORT  -  BOTH  3 

, 690.93 

MAN-DAYS 

Figure  20.  Simulation  1 — Statistical  Results 


are  presented  for  project  one  first  followed  by  those  for 
project  two.  Finally,  the  net  transfers  between  projects 
(transfers  from  a  project  subtracted  from  transfers  into 
that  project)  are  shown  followed  by  the  total  effort  in  man- 
days  of  the  combined  projects.  It  is  the  total  effort, 
whether  for  each  project  or  combined,  which  represents  the 
"cost”  inherent  to  each  situation. 
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Graphical  reports  identical  in  format  to  Figures  21 
and  22  will  also  be  presented  for  each  simulation  throughout 
this  and  the  following  section.  Figure  21  illustrates  the 
relationship  between  the  scheduled  completion  dates 
(SCHCDT) ,  measured  in  days,  of  the  two  projects  as  well  as 
the  relationship  between  the  total  workforce  (TOTWF) , 
measured  in  men,  of  both  projects.  Also  of  interest  is  the 
relative  relationship  between  the  values  of  these  variables 
themselves.  For  instance,  project  two  has  neither  a 
scheduled  completion  date  or  any  workforce  assigned  it  until 
it  begins  at  time  100.  Once  it  begins,  however,  the 
scheduled  completion  date  remains  relatively  stable  then 
drops  and  finally  rises  again.  The  total  workforce 
consistently  rises  throughout  the  life  of  the  project  and 
then  drops  rapidly  once  it  is  completed.  Comparisons  of 
absolute  values  of  these  variables  is  inadvisable  because 
they  are  plotted  on  different  scales,  as  can  be  seen  on  the 
left  hand  side  of  the  graphs.  Identification  of  which  scale 
belongs  to  which  variable  can  be  made  by  comparing  the 
minimum  and  maximum  value  of  the  scale  to  the  figures 
immediately  following  the  variables  at  the  top  of  the 
graph . 

Figure  22  presents  the  relationship  between  the 
total  workforce  (TOTWF)  and  the  transferred  workforce 
(TRNFWF) ,  both  of  which  are  measured  in  number  of  men. 

Recall  that  as  transferred  individuals  are  assimilated  into 
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Figure  21.  Simulation  1 — Graph  1 
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the  workforce  of  the  gaining  project,  they  become 
experienced  workforce  and  are  no  longer  reflected  in  the 
TRNFWF  value.  Caution  is  once  again  advised  in  any  attempt 
to  compare  absolute  values  for  these  variables  for  the  same 
reason  mentioned  in  the  paragraph  above.  More  interesting, 
in  any  case,  is  their  movement  on  the  graph  relative  to  each 
other.  Since  in  this  simulation,  as  in  most  simulations, 
project  one  has  priority,  there  will  be  no  transfers  to 
project  two  until  project  one  completes.  Note  that  in  both 
graphs,  as  in  all  graphs  presented  as  simulation  results, 
time  is  measured  in  days. 

2.  TRPYll 

In  this  simulation,  the  priority  of  the  projects 
(TRPYll)  was  switched  (from  TRPYll  =  1  to  TRYP11  =0).  In 
the  default,  project  one  has  priority.  In  this  simulation, 
project  two  was  given  priority  and  as  such  all  transfers 
would  occur  in  the  direction  of  project  one  to  project  two 
until  project  two  completes.  Results  from  this  run  are 
shown  in  Figures  23,  24,  and  25. 

3.  PRTYSW 

The  third  simulation  in  this  set  involved  changing 
the  way  in  which  priority  is  determined.  Instead  of  a 
single  project  always  having  priority  (PRTYSW  =  l) ,  as 
determined  exogenously  by  management,  the  priority  in  this 
simulation  is  determined  dynamically  (PRTYSW  =  0) .  This  is 
comparable  to  the  conditions  under  which  the  first  five 
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Figure  23.  Simulation  2 — Statistical  Results 
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simulations  in  experiment  set  one  were  run.  Results  from 
this  simulation  are  shown  in  Figures  26,  27,  and  28. 

4.  P0LCY1 

In  this  simulation,  the  variable  changed  was  that 
which  affects  the  management  policy  regarding  how  the 
workforce  ceiling  is  allocated  (P0LCY1) .  In  lieu  of  having 
a  50:50  allocation  (P0LCY1  =1),  in  which  each  project  gets 
50  percent  of  the  ceiling,  the  policy  was  changed  (P0LCY1  = 
0) .  This  simulation  represents  the  effects  of  an  allocation 
policy  in  which  the  project  which  has  priority  is  allowed  to 
hire  in  whatever  numbers  it  needs  up  to  the  ceiling;  the 
second  project  can  hire  only  the  workforce  representing  the 
difference  between  what  the  first  project  has  hired  and  the 
organizations]  ceiling.  Of  note  is  the  fact  that  in  either 
case  the  default  ceiling  of  30  is  sufficient  for  both 
projects  to  complete  on  time  without  undue  pressure 
resulting  from  this  ceiling  if  the  workforce  is  acquired 
early  enough  to  allow  for  assimilation.  Results  from  this 
simulation  are  presented  in  Figures  29,  30,  and  31. 

5 .  TAGRSV 

In  the  fifth  simulation,  the  variable  affecting  the 
aggressiveness  of  the  manager  and  his  willingness  to  change 
the  workforce  assuming  transfers  will  occur  (TAGRSV)  is 
changed.  It  is  decreased  from  one  to  .5.  The  consequence 
of  this  change  is  to  simulate  a  manager  who  is  more  willing 
to  transfer  people  from  the  other  project  (project  two) . 
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Figure  26.  Simulation  3 — Statistical  Results 
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Figure  27.  Simulation  3 — Graph  1 
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Figure  29.  Simulation  4 — Statistical  Results 
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Figure  30.  Simulation  4 — Graph  1 
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Results  from  this  simulation  are  shown  in  Figures  32,  33, 
and  34. 

6.  T2T1F2  and  T1T2F2 

Similar  to  the  fifth  simulation,  the  effect  of  the 
change  in  this  run  of  the  model  was  to  simulate  a  manager 
who  is  more  willing  to  transfer  workforce  by  force  from  the 
other  project  to  meet  his  manpower  needs.  These  variables 
(T2T1F2  and  T1T2F2)  model  willingness  to  force  transfers  as 
a  function  of  the  percent  reported  completed  of  the  second 
project.  They  are  originally  set  to  values  which  indicate 
an  unwillingness  on  the  manager’s  part  to  force  transfers 
from  a  project  just  beginning.  This  is  because  the  manager 
realizes  the  importance  of  not  disrupting  a  project  in  its 
early  stages,  when  it  is  building  its  core  team.  Thus  even 
though  project  one  has  priority,  its  manager  would  not  be 
willing  to  force  transfers  from  project  two  because  he  knew 
it  was  in  its  "building  up"  stage.  In  this  case  both  the 
variable  affecting  project  one  and  its  equivalent  (T2T1F2 
and  T2T1F2)  were  increased  in  value  such  that  this  period  of 
non-disruption  is  denied.  The  default  values  of  these 
variables  are  0/. 2/. 5/. 9/1/1  while  the  new  values  as  used  in 
this  simulation  are  l/l/l/l/l/l.  Values  such  as  these 
represent  table  functions  in  the  Dynamo  language.  In  table 
functions  each  number  is  associated  with  the  occurrence  of 
an  event.  For  instance,  in  this  example,  a  manager  would 
have  "0"  willingness  to  force  transfers  when  project  two  was 
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Figure  32.  Simulation  5 — Statistical  Results 
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Figure  33.  Simulation  5 — Graph  1 
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Figure  34.  Simulation  5 — Graph  2 
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reporting  zero  percent  completion.  A  more  detailed 
discussion  of  the  table  function  and  its  application,  while 
beyond  the  scope  of  this  work,  can  be  found  in  Alexander 
Pugh's  book,  Dvnamo  User's  Manual.  However,  in  several 
cases  these  types  of  values  are  included  in  the  description 
of  the  simulation  to  enable  duplication  of  these  simulations 
in  follow-up  research.  Results  from  this  simulation  are 
given  in  Figures  35,  36,  and  37. 

7.  TB2T11  and  TB1T21 

In  this  simulation  another  variable  and  its 
equivalent  (TB2T11  and  TB1T21)  were  changed.  These 
variables  are  used  in  conjunction  with  those  described  in 
simulation  eight  to  ascertain  the  overall  fraction  of  his 
workforce  the  manager  can  be  forced  to  transfer.  These 
variables  provide  input  to  this  fraction  as  a  function  of 
the  percent  reported  completed  of  the  second  project.  In 
the  default  situation  project  one  will  not  force  transfers 
from  project  two  at  all  until  it  is  at  least  ten  percent 
complete.  The  contribution  of  these  two  variables  is  zero 
until  this  time  causing  a  zero  fraction  of  the  workforce  to 
be  forcibly  transferred.  The  change  effected  in  this 
simulation  was  such  that  these  variables  no  longer  had  any 
effect  on  the  overall  fraction  of  the  workforce  to  be  trans¬ 
ferred — a  simulation  which  could  be  used  to  ascertain  if  the 
concept  which  these  variables  model  is  an  actual  concern  of 
managers.  If  the  change  does  not  produce  significantly 
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Figure  35.  Simulation  6 — Statistical  Results 
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Figure  36.  Simulation  6 — Graph  1 
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Figure  37.  Simulation  6 — Graph  2 


different  results  from  the  baseline  case,  then  this  variable 
has  little  effect  on  the  manager's  decision.  The  default 
values  of  these  variables  are  0/ . 2/ . 5/ . 9/1/1  and  the  values 
on  which  this  simulation  were  based  are  l/l/l/l/l/l. 

Figures  38,  39,  and  40  illustrate  the  results. 

8.  TC2T11  and  TC1T21 

In  this  simulation  the  variable  affecting  the 
fraction  of  his  workforce  a  manager  can  be  forced  to 
transfer  as  a  function  of  the  cumulative  recentness  of 
transfers  and  its  equivalent  in  the  other  project  are 
increased  (TC2T11  and  TC1T21) .  These  variables  are  used  in 
conjunction  with  those  described  in  simulation  seven  to 
ascertain  the  overall  fraction  of  his  workforce  the  manager 
can  be  forced  to  transfer.  The  default  values  of  these 
variables  (11  values  ranging  from  .5  to  zero)  are  such  that 
if  a  manager  has  recently  transferred  out  a  large  portion  of 
his  workforce  he  will  not  be  forced  to  transfer  any  more 
individuals  at  the  present  time.  These  values  were 
increased  (all  11  values  are  now  equal  to  the  value  one) . 

The  change  effected  in  this  simulation  was  such  that  these 
variables  no  longer  had  any  affect  on  the  overall  fraction 
of  the  workforce  to  be  transferred — a  simulation  which  could 
be  used  to  ascertain  if  the  concept  which  these  variables 
model  is  an  actual  concern  of  managers.  If  the  change  does 
not  produce  significantly  different  results  from  the  baseline 
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Figure  38.  Simulation  7 — Statistical  Results 
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case  then  this  variable  has  little  effect  on  the  manager's 
decision.  Figures  41,  42,  and  43  pertain. 


9.  FORGETa 

In  the  ninth  simulation,  the  time  it  takes  a  manager 
to  "forget"  about  recent  transfers  (FORGET)  was  decreased 
from  the  default  value  of  60  to  30.  This  variable  affects 
the  willingness  of  that  manager  to  transfer  more  of  his 
workforce.  The  lower  the  value  of  this  variable,  the  more 
apt  the  manager  is  to  allow  transfers  as  he  has  already 
forgotten  about  relatively  recent  transfers.  Results  are 
provided  in  Figures  44,  45,  and  46. 

10.  FORGETb 

The  amount  of  time  it  takes  a  manager  to  "forget" 
about  recent  transfers  (FORGET)  was  increased  over  the 
default  value  from  60  to  120.  More  information  is  provided 
in  the  description  of  simulation  nine.  See  the  results  in 
Figures  47,  48,  and  49. 

11.  TMP1R2  and  TMP1R1 

In  this  experiment,  the  impact  of  the  hiring  ceiling 
on  the  willingness  to  force  transfers  from  a  project  because 
its  workforce  could  be  replenished  is  changed  as  is  its 
equivalent  in  the  other  project  (TMP1R2  and  TMP1R1) .  This 
change  allows  simulation  of  a  situation  in  which  the  ceiling 
has  less  of  an  impact  on  the  final  decision  than  in  the 
baseline  case.  Note  that  the  result  of  the  change  is  less 
of  an  impact  although  the  default  values  of  these  variables 
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QA  EFFORT  TWO 

416.35 

MAN-DAYS 

.23 

DEVELOP  EFFORT 

TWO 

870.64 

MAN-DAYS 

.48 

REWORK  EFFORT  TWO 

262.37 

MAN-DAYS 

.14 

TESTING  EFFORT 

TWO 

236.57 

MAN-DAYS 

.13 

TRAINING  EFFORT 

TWO 

23.96 

MAN-DAYS 

.01 

OVERALL-PRODUCTIVITY 

TWO 

13.48 

TASKS/MAN-DAY 

NET  TRANSFERS  2  TO  1 

-  8.24 

MEN 

NET  TRANSFERS  1  TO  2 

8.24 

MEN 

TOTAL  EFFORT  -  BOTH 

3 

,659.45 

MAN-DAYS 

Figure  41.  Simulation  8 — Statistical  Results 
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PROJECT  STATISTICS: 

COMPLETION  TIME  ONE 

374.50 

PORTION  OF 
TOTAL  EFFORT 

DAYS 

TOTAL  EFFORT  ONE  1 

,863.02 

MAN-DAYS 

QA  EFFORT  ONE 

457.20 

MAN-DAYS 

.25 

DEVELOP  EFFORT  ONE 

863.15 

MAN-DAYS 

.46 

REWORK  EFFORT  ONE 

261.58 

MAN-DAYS 

.14 

TESTING  EFFORT  ONE 

232.22 

MAN-DAYS 

.12 

TRAINING  EFFORT  ONE 

48.86 

MAN-DAYS 

.03 

OVERALL-PRODUCTIVITY  ONE 

13.10 

TASKS/MAN-DAY 

COMPLETION  TIME  TWO 

519.50 

DAYS 

TOTAL  EFFORT  TWO  1 

,827.91 

MAN-DAYS 

QA  EFFORT  TWO 

411.77 

MAN-DAYS 

.23 

DEVELOP  EFFORT  TWO 

881.43 

MAN-DAYS 

.48 

REWORK  EFFORT  TWO 

265.20 

MAN-DAYS 

.15 

TESTING  EFFORT  TWO 

245.93 

MAN-DAYS 

.13 

TRAINING  EFFORT  TWO 

23.58 

MAN-DAYS 

.01 

OVERALL- PRODUCTIVITY  TWO 

13.35 

TASKS/MAN-DAY 

NET  TRANSFERS  2  TO  1 

-  8.84 

MEN 

NET  TRANSFERS  1  TO  2 

8.84 

MEN 

TOTAL  EFFORT  -  BOTH  3 

,690.93 

MAN-DAYS 

Figure  44.  Simulation  6 — Statistical  Results 
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Figure  46.  Simulation  9 — Graph  2 


PROJECT  STATISTICS: 


PORTION  OF 
TOTAL  EFFORT 


COMPLETION  TIME  ONE 

- 

377.50 

DAYS 

TOTAL  EFFORT  ONE 

1 

,875.87 

MAN-DAYS 

QA  EFFORT  ONE 

462.83 

MAN-DAYS 

.25 

DEVELOP  EFFORT 

ONE 

866.13 

MAN-DAYS 

.46 

REWORK  EFFORT  ONE 

262.02 

MAN-DAYS 

.  14 

TESTING  EFFORT 

ONE 

233.66 

MAN-DAYS 

.  12 

TRAINING  EFFORT 

ONE 

51.22 

MAN-DAYS 

.03 

OVERALL-PRODUCTIVITY 

ONE 

13.01 

TASKS/MAN-DAY 

COMPLETION  TIME  TWO 

501.50 

DAYS 

TOTAL  EFFORT  TWO 

1 

,866.19 

MAN-DAYS 

QA  EFFORT  TWO 

413.94 

MAN-DAYS 

.22 

DEVELOP  EFFORT 

TWO 

895.97 

MAN-DAYS 

.48 

REWORK  EFFORT  TWO 

269.71 

MAN-DAYS 

.14 

TESTING  EFFORT 

TWO 

257.39 

MAN-DAYS 

.  14 

TRAINING  EFFORT 

TWO 

29.17 

MAN-DAYS 

.02 

OVERALL-PRODUCTIVITY 

TWO 

13 . 07 

TASKS/MAN-DAY 

NET  TRANSFERS  2  TO  1 

-  9.34 

MEN 

NET  TRANSFERS  1  TO  2 

9.34 

MEN 

TOTAL  EFFORT  -  BOTH 

3 

,742.06 

MAN-DAYS 

Figure  47.  Simulation  10 — Statistical  Results 
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were  increased  from  0/. 5/. 75/. 9/. 975/1/1/1/1/1/1  to  all 
one’s.  The  results  of  the  simulation  are  presented  in 
Figures  50,  51,  and  52. 

12.  TWRL2Tla  and  TWRLlT2a 

The  manager’s  willingness  to  rely  on  the  release  of 
people  from  a  completing  project  and  its  equivalent  in  the 
other  project  are  the  independent  variables  in  this 
simulation  (TWRL2T1  and  TWRL1T2).  This  willingness  is  a 
ratio  of  the  time  remaining  (for  the  completing  project)  to 
the  hiring  delay;  the  higher  the  ratio,  the  less  apt  the 
manager  is  to  wait  in  the  baseline  scenario.  In  this 
simulation,  this  willingness  was  increased,  from 
1/. 5/. 25/. 1/0/0,  the  default  values,  to  l/l/l/l/l/l.  This 
increase  simulates  a  manager  who  is  always  willing  to  rely 
on  release  of  personnel  from  the  other  project  regardless  of 
how  much  longer  it  has  before  completion.  Figures  53,  54, 
and  55  provide  results. 

13.  TWRL2Tlb  and  TWRLlT2b 

Once  again,  the  manager's  willingness  to  rely  on  the 
release  of  people  from  a  completing  project  is  the 
independent  variable.  However,  in  this  case,  this 
willingness  was  decreased  from  the  default  values  given  in 
the  description  of  simulation  12  to  0/0/0/ 0/0/0.  This 
decrease  causes  the  situation  in  which  the  manager  will 
never  rely  on  people  from  the  other  project  based  on  its 
completion.  Figures  56,  57,  and  58  are  relevant. 
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PROJECT  STATISTICS: 


PORTION  OF 
TOTAL  EFFORTl 


COMPLETION  TIME  ONE 

374.50 

DAYS 

TOTAL  EFFORT  ONE 

1 

,863.02 

MAN-DAYS 

QA  EFFORT  ONE 

457.20 

MAN-DAYS 

.25 

DEVELOP  EFFORT 

ONE 

863.15 

MAN-DAYS 

.46 

REWORK  EFFORT  ONE 

261.58 

MAN-DAYS 

.14 

TESTING  EFFORT 

ONE 

232.22 

MAN-DAYS 

.12 

TRAINING  EFFORT 

ONE 

48.86 

MAN-DAYS 

.03 

OVERALL-PRODUCTIVITY 

ONE 

13.10 

TASKS/MAN-DAY 

COMPLETION  TIME  TWO 

519.50 

DAYS 

TOTAL  EFFORT  TWO 

1 

,827.91 

MAN-DAYS 

QA  EFFORT  TWO 

411.77 

MAN-DAYS 

.23 

DEVELOP  EFFORT 

TWO 

881.43 

MAN-DAYS 

.48 

REWORK  EFFORT  TWO 

265.20 

MAN-DAYS 

.15 

TESTING  EFFORT 

TWO 

245.93 

MAN-DAYS 

.  13 

TRAINING  EFFORT 

TWO 

23.58 

MAN-DAYS 

.01 

OVERALL-PRODUCTIVITY 

TWO 

13.35 

TASKS/MAN-DAY 

NET  TRANSFERS  2  TO  1 

-  8.84 

MEN 

NET  TRANSFERS  1  TO  2 

8.84 

MEN 

TOTAL  EFFORT  -  BOTH 

3 

,  690.93 

MAN-DAYS 

Figure  50.  Simulation  11 — Statistical  Results 
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8.  188.  288.  388.  488. 

DAYS 


Figure  51.  Simulation  11 — Graph  1 


Figure  52.  Simulation  11 — Graph  2 


PROJECT  STATISTICS: 


PORTION 

OF 

COMPLETION  TIME  ONE 

391.00 

TOTAL  EFFOR' 

DAYS 

TOTAL  EFFORT  ONE  1 

,923.60 

MAN-DAYS 

QA  EFFORT  ONE 

482.27 

MAN-DAYS 

.25 

DEVELOP  EFFORT  ONE 

873.82 

MAN-DAYS 

.  45 

REWORK  EFFORT  ONE 

264.67 

MAN-DAYS 

.  14 

TESTING  EFFORT  ONE 

235.45 

MAN-DAYS 

.  12 

TRAINING  EFFORT  ONE 

67.38 

MAN-DAYS 

.  04 

OVERALL-PRODUCTIVITY  ONE 

12.68 

TASKS/MAN-DAY 

COMPLETION  TIME  TWO 

618.50 

DAYS 

TOTAL  EFFORT  TWO  1, 

,846.52 

MAN-DAYS 

QA  EFFORT  TWO 

443.25 

MAN-DAYS 

.  24 

DEVELOP  EFFORT  TWO 

875.76 

MAN-DAYS 

.  47 

REWORK  EFFORT  TWO 

256.62 

MAN-DAYS 

.  14 

TESTING  EFFORT  TWO 

259.72 

MAN-DAYS 

.  14 

TRAINING  EFFORT  TWO 

11.17 

MAN-DAYS 

.  01 

OVERALL-PRODUCTIVITY  TWO 

13.21 

TASKS/MAN-DAY 

NET  TRANSFERS  2  TO  1 

■  12.85 

MEN 

NET  TRANSFERS  1  TO  2 

12 . 85 

MEN 

TOTAL  EFFORT  -  BOTH  3 , 

770.12 

MAN-DAYS 

Figure  53.  Simulation  12 — Statistical  Results 


PROJECT  STATISTICS: 


PORTION  OF  I 
TOTAL  EFFORT! 


COMPLETION  TIME  ONE 

364.50 

DAYS 

TOTAL  EFFORT  ONE  1 

,889.58 

MAN-DAYS 

QA  EFFORT  ONE 

454.99 

MAN-DAYS 

.24 

DEVELOP  EFFORT  ONE 

869.06 

MAN-DAYS 

.46 

REWORK  EFFORT  ONE 

263.34 

MAN-DAYS 

.14 

TESTING  EFFORT  ONE 

256.79 

MAN-DAYS 

.14 

TRAINING  EFFORT  ONE 

45.40 

MAN-DAYS 

.02 

OVERALL-PRODUCTIVITY  ONE 

12.91 

TASKS/MAN-DAY 

COMPLETION  TIME  TWO 

498.00 

DAYS 

TOTAL  EFFORT  TWO  1 

,843.48 

MAN-DAYS 

QA  EFFORT  TWO 

440.19 

MAN-DAYS 

.24 

DEVELOP  EFFORT  TWO 

860.73 

MAN-DAYS 

.47 

REWORK  EFFORT  TWO 

262.68 

MAN-DAYS 

.14 

TESTING  EFFORT  TWO 

231.88 

MAN-DAYS 

.13 

TRAINING  EFFORT  TWO 

47.98 

MAN-DAYS 

.03 

OVERALL-PRODUCTIVITY  TWO 

13.24 

TASKS/MAN-DAY 

NET  TRANSFERS  2  TO  1 

6.34 

MEN 

NET  TRANSFERS  1  TO  2 

-  6.34 

MEN 

TOTAL  EFFORT  -  BOTH  3 

,733.06 

MAN-DAYS 

Figure  56.  Simulation  13 — Statistical  Results 
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Figure  57.  Simulation  13 — Graph  1 
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14 .  Summary 


This  set  of  experiments  supports  comparisons  of 
costs  in  simulations  in  which  the  project  starting  first  has 
priority.  In-depth  analysis  of  each  simulation  is  of 
interest  to  the  manager  wishing  to  understand  in  more  detail 
the  complexities  of  software  project  management.  Following 
is  a  brief  analysis  of  two  of  the  simulations  in  this 
experiment  set. 

Simulation  three  resulted  in  costs  higher  than 
average  for  this  experiment  set.  In  this  simulation,  the 
project  which  will  have  priority  is  determined  by  the  model 
as  a  function  of  which  project's  indicated  completion  date 
is  farthest  from  its  scheduled  completion  date.  That 
project  in  the  most  trouble,  i.e.,  whose  indicated 
completion  date  is  farthest  from  its  scheduled  completion 
date,  will  receive  transfers.  This  scenario  causes  an 
increase  in  the  number  of  transfers  over  the  baseline 
results  as  priority  is  continually  reassigned  back  and  forth 
between  projects.  Additional  transfers  cause  increased 
training  and  assimilation  time  and  decrease  overall 
productivity.  This  in  turn  causes  a  greater  expenditure  of 
effort,  resulting  in  the  increased  costs  seen  in  this 
simulation. 

One  of  the  most  interesting  results  of  this 
experiment  set  was  attained  when  the  way  in  which  the 
workforce  ceiling  was  allocated  was  changed.  This  change 
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was  effected  in  simulation  four.  Instead  of  each  project 
being  allocated  50  percent  of  new  hires,  up  to  the  workforce 
ceiling  for  the  organization,  the  project  having  priority, 
project  one,  is  allowed  to  hire  what  it  wants  up  to  the 
ceiling.  If  the  ceiling  is  not  reached,  project  two  can 
then  hire  up  to  the  ceiling.  Project  two,  therefore,  is 
unable  to  hire  in  the  numbers  it  would  like.  This  causes 
project  two  to  rely  on  transfers  from  project  one,  after 
project  one  has  completed.  This  increased  number  of 
transfers  relatively  late  in  project  two's  development 
causes  decreased  productivity  and  increased  costs. 

These  brief  analyses  provide  the  reader  with  some 
insight  into  how  different  management  decisions  can  affect 
the  costs  of  developing  software  projects  in  a  multiproject 
environment.  As  in  experiment  set  one,  a  more  detailed 
analysis  of  these  results  is  an  appropriate  area  for  follow- 
on  research. 

E.  EXPERIMENT  SET  THREE 

The  third  set  of  experiments  involved  simulations  run 
when  the  project  starting  last  had  priority.  As  illustrated 
in  Figure  17,  costs  were  at  a  low  point  when  the  project 
having  priority,  project  one,  began  100  days  after  the 
project  without  priority.  The  actual  minimum  cost  appears 
to  be  at  time  300  but  running  simulations  with  this  great  a 
disparity  in  start  dates  would  minimize  the  effects  of  the 
overlap  mechanism.  In  each  of  the  follow-on  simulations  run 
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under  this  scenario,  the  start  date  of  the  first  project  was 
set  to  100.  In  all  other  ways,  this  set  of  experiments  is 
identical  to  those  run  in  experiment  set  two.  For  ease  in 
reading,  the  descriptions  of  the  simulations  are  repeated 
here.  Recall  that  other  parameters  of  note  which  remained 
unchanged  throughout  this  scenario,  unless  otherwise 
indicated,  include  the  project  priority  and  the  workforce 
ceiling  allocation  policy.  Table  2  provides  a  summary  of 
the  simulations  run  in  this  set  of  experiments.  These 
results  are  graphically  presented  in  Figure  59. 

1 .  Baseline 

The  first  simulation  presented  is  the  "baseline" 
simulation  in  which  project  one  has  higher  priority,  project 
one  started  100  days  after  project  two,  the  workforce 
ceiling  allocation  policy  is  50:50,  and  the  ceiling  on  the 
total  workforce  is  30.  This  simulation  provides  a  basis  for 
comparisons  with  others  within  this  experiment  set.  Figures 
60,  61,  and  62  pertain. 

2.  TRPY11 

In  this  simulation,  the  priority  of  the  projects 
(TRPY11 )  was  switched  (from  TRPY11  =  1  to  TRYP11  =  0) .  In 
the  default,  project  one  has  priority.  In  this  simulation, 
project  two  was  given  priority  and  as  such  all  transfers 
would  occur  in  the  direction  of  project  one  to  project  two 
until  project  two  completes.  Results  from  this  run  are 
shown  in  Figures  63,  64,  and  65. 
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TABLE  2 


RESULTS  FROM  EXPERIMENT  SET  THREE  SIMULATIONS 


■ 

Independent 

Variable 

Cost 

(Man-days) 

Schedule 

(Days) 

Transfers 
2  to  1 

Transfers 
1  to  2 

1 

BASELINE 

3790.05 

440.50 

-3.28 

3.28 

2 

TRPY11 

488.50 

7.61 

-7.61 

3 

PRTYSW 

3951.43 

465.00 

13.99 

-13.99 

4 

POLCY1 

3841.57 

440.50 

-4.62 

4.62 

5 

TAGRSV 

3788.37 

442.00 

-3.16 

3.16 

6 

T2T1F2 

T1T2F2 

3790.23 

440.50 

-3.28 

3.28 

1 

TB2T11 

TB1T21 

3790.05 

440.50 

-3.28 

3.28 

8 

TC2T11 

TC1T21 

3952.07 

456.50 

-3.80 

3.80 

9 

FORGETa 

3940.73 

451.50 

-3.73 

3.73 

10 

FORGETb 

3746.54 

431.00 

6.38 

-6.38 

11 

TMP1R2 

TMP1R1 

3790.10 

440.50 

-3.28 

3 . 28 

B 

TWRL2Tla 

TWRLlT2a 

3710.61 

446.00 

20.12 

-20.12 

13 

TWRL2Tlb 

WRLlT2b 

3782.80 

467.00 

11.12 

-11.12 

88 


Figure  59.  Graphic  Results  of  Experiment  Set  Three 

3.  PRTYSW 

The  third  simulation  in  this  set  involved  changing 
the  way  in  which  priority  is  determined.  Instead  of  a 
single  project  always  having  priority  (PRTYSW  =  1) ,  as 
determined  exogenously  by  management,  the  priority  in  this 
simulation  is  determined  dynamically  (PRTYSW  =  0) .  This  is 
comparable  to  the  conditions  under  which  the  first  five 
simulations  in  experiment  set  one  were  run.  Results  from 
this  simulation  are  shown  in  Figures  66,  67,  and  68. 
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PROJECT  STATISTICS: 


PORTION  OF 
TOTAL  EFFORT 
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414.50 

DAYS 

TOTAL  EFFORT  ONE 

1 

,845.33 

MAN-DAYS 

QA  EFFORT  ONE 
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MAN-DAYS 

.23 

DEVELOP  EFFORT 

ONE 

884.84 

MAN-DAYS 

.48 

REWORK  EFFORT  ONE 

265.80 

MAN-DAYS 

.  14 

TESTING  EFFORT 

ONE 

248.48 

MAN-DAYS 

.  13 

TRAINING  EFFORT 

ONE 

24.68 

MAN-DAYS 

.01 

OVERALL-PRODUCTIVITY 

ONE 

13.22 

TASKS/MAN-DAY 

COMPLETION  TIME  TWO 

440.50 

DAYS 

TOTAL  EFFORT  TWO 

1 

,944.72 

MAN-DAYS 

QA  EFFORT  TWO 

500.88 

MAN-DAYS 

.26 

DEVELOP  EFFORT 

TWO 

875.78 

MAN-DAYS 

.45 

REWORK  EFFORT  TWO 

257.95 

MAN-DAYS 

.13 

TESTING  EFFORT 

TWO 

260.48 

MAN-DAYS 

.  13 

TRAINING  EFFORT 

TWO 

49.64 

MAN-DAYS 

.03 

OVERALL-PRODUCTIVITY 

TWO 

12.55 

TASKS/MAN-DAY 

NET  TRANSFERS  2  TO  1 

-  3.28 

MEN 

NET  TRANSFERS  1  TO  2 

3 . 28 

MEN 

TOTAL  EFFORT  -  BOTH 

3 

,790.05 

MAN-DAYS 

Figure  60.  Simulation  1 — Statistical  Results 
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Figure  61.  Simulation  1 — Graph  l 
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PROJECT  STATISTICS: 

PORTION 

OF 

TOTAL  EFFORTI 

COMPLETION  TIME  ONE 

488.50 

DAYS 

TOTAL  EFFORT  ONE  1 

,838.67 

MAN-DAYS 

QA  EFFORT  ONE 

412.70 

MAN-DAYS 

.22 

DEVELOP  EFFORT  ONE 

886.90 

MAN-DAYS 

.48 

REWORK  EFFORT  ONE 

265.44 

MAN-DAYS 

.  14 

TESTING  EFFORT  ONE 

247.70 

MAN-DAYS 

.  13 

TRAINING  EFFORT  ONE 

25.93 

MAN-DAYS 

.01 

OVERALL-PRODUCTIVITY  ONE 

13.27 

TASKS/MAN-DAY 

COMPLETION  TIME  TWO 

370.00 

DAYS 

TOTAL  EFFORT  TWO  1 

,852.70 

MAN-DAYS 

QA  EFFORT  TWO 

452.16 

MAN-DAYS 

.24 

DEVELOP  EFFORT  TWO 

861.86 

MAN-DAYS 

.47 

REWORK  EFFORT  TWO 

260.14 

MAN-DAYS 

.14 

TESTING  EFFORT  TWO 

236.08 

MAN-DAYS 

.  13 

TRAINING  EFFORT  TWO 

42.45 

MAN-DAYS 

.02 

OVERALL-PRODUCTIVITY  TWO 

13.17 

TASKS/MAN-DAY 

NET  TRANSFERS  2  TO  1 

7.61 

MEN 

NET  TRANSFERS  1  TO  2 

-  7.61 

MEN 

TOTAL  EFFORT  -  BOTH  3 

,691.37 

MAN-DAYS 

Figure  63.  Simulation  2 — Statistical  Results 
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DAYS/MEN 


DAYS 

Figure  64.  Simulation  2 — Graph  1 


PROJECT  STATISTICS: 


PORTION  OF 
TOTAL  EFFOR' 


COMPLETION  TIME  ONE  __  465.00  DAYS 
TOTAL  EFFORT  ONE  2,028.94  MAN-DAYS 

QA  EFFORT  ONE  517.28  MAN-DAYS  .25 
DEVELOP  EFFORT  ONE  933.40  MAN-DAYS  .46 
REWORK  EFFORT  ONE  268.56  MAN-DAYS  .13 
TESTING  EFFORT  ONE  285.46  MAN-DAYS  .14 
TRAINING  EFFORT  ONE  24.24  MAN-DAYS  .01 


OVERALL-PRODUCTIVITY  ONE  12.03  TASKS/MAN-DAY 


COMPLETION  TIME  TWO  399.00  DAYS 
TOTAL  EFFORT  TWO  1,922.49  MAN-DAYS 

QA  EFFORT  TWO  494.60  MAN-DAYS  .26 
DEVELOP  EFFORT  TWO  882.91  MAN-DAYS  .46 
REWORK  EFFORT  TWO  262.31  MAN-DAYS  .14 
TESTING  EFFORT  TWO  240.34  MAN-DAYS  .13 
TRAINING  EFFORT  TWO  42.32  MAN-DAYS  .02 


OVERALL-PRODUCTIVITY  TWO  12.69  TASKS/MAN-DAY 


NET  TRANSFERS  2  TO  1  13.99  MEN 

NET  TRANSFERS  1T02  -13.99  MEN 

TOTAL  EFFORT  -  BOTH _ 3,951.43  MAN-DAYS _ 

Figure  66.  Simulation  3 — Statistical  Results 
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Figure  67.  Simulation  3 — Graph  1 
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4. 


P0LCY1 


In  this  simulation,  the  variable  changed  was  that 
which  affects  the  management  policy  regarding  how  the  work¬ 
force  ceiling  is  allocated  (POLCY1) .  In  lieu  of  having  a 
50:50  allocation  (P0LCY1  =1),  in  which  each  project  gets  50 
percent  of  the  ceiling,  the  policy  was  changed  (POLCY1  =  0) . 
This  simulation  represents  the  effects  of  an  allocation 
policy  in  which  the  project  which  has  priority  is  allowed  to 
hire  in  whatever  numbers  it  needs  up  to  the  ceiling;  the 
second  project  can  hire  only  the  workforce  representing  the 
difference  between  what  the  first  project  has  hired  and  the 
organizational  ceiling.  Of  note  is  the  fact  that  in  either 
case  the  default  ceiling  of  30  is  sufficient  for  both 
projects  to  complete  on  time  without  undue  pressure 
resulting  from  this  ceiling  if  the  workforce  is  acquired 
early  enough  to  allow  for  assimilation.  Results  from  this 
simulation  are  presented  in  Figures  69,  70,  and  71. 

5.  TAGRSV 

In  the  fifth  simulation,  the  variable  affecting  the 
aggressiveness  of  the  manager  and  his  willingness  to  change 
the  workforce  assuming  transfers  will  occur  (TAGRSV)  is 
changed.  It  is  decreased  from  one  to  .5.  The  consequence 
of  this  change  is  to  simulate  a  manager  who  is  more  willing 
to  transfer  people  from  the  other  project  (project  two) . 
Results  from  this  simulation  are  shown  in  Figures  72,  73, 
and  74. 
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PROJECT  STATISTICS: 


PORTION  OF 
TOTAL  EFFORTl 


COMPLETION  TIME  ONE 

413.50 

DAYS 

TOTAL  EFFORT  ONE 

1 

,883.78 

MAN-DAYS 

QA  EFFORT  ONE 

429.59 

MAN-DAYS 

.23 

DEVELOP  EFFORT 

ONE 

896.17 

MAN-DAYS 

.48 

REWORK  EFFORT  ONE 

269.52 

MAN-DAYS 

.  14 

TESTING  EFFORT 

ONE 

257.30 

MAN-DAYS 

.14 

TRAINING  EFFORT 

ONE 

31.20 

MAN-DAYS 

.  02 

OVERALL-PRODUCTIVITY 

ONE 

12.95 

TASKS/MAN-DAY 

COMPLETION  TIME  TWO 

440.50 

DAYS 

TOTAL  EFFORT  TWO 

1 

,957.79 

MAN-DAYS 

QA  EFFORT  TWO 

496.23 

MAN-DAYS 

.25 

DEVELOP  EFFORT 

TWO 

875.58 

MAN-DAYS 

.45 

REWORK  EFFORT  TWO 

257.68 

MAN-DAYS 

.  13 

TESTING  EFFORT 

TWO 

274.57 

MAN-DAYS 

.  14 

TRAINING  EFFORT 

TWO 

53.73 

MAN-DAYS 

.03 

OVERALL-PRODUCTIVITY 

TWO 

12.46 

TASKS/MAN-DAY 

NET  TRANSFERS  2  TO  1 
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NET  TRANSFERS  1  TO  2 

4.62 
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TOTAL  EFFORT  -  BOTH 

3 

,841.57 

MAN-DAYS 

Figure  69.  Simulation  4 — Statistical  Results 
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Figure  70.  Simulation  4 — Graph  1 


PROJECT  STATISTICS: 


PORTION  OF 
TOTAL  EFFORH 


COMPLETION  TIME  ONE 

414.00 

DAYS 

TOTAL  EFFORT  ONE 

1 

,847.91 

MAN-DAYS 

QA  EFFORT  ONE 

421.56 

MAN-DAYS 

.23 

DEVELOP  EFFORT 

ONE 

884.92 

MAN-DAYS 

.48 

REWORK  EFFORT  ONE 

265.72 

MAN-DAYS 

.  14 

TESTING  EFFORT 

ONE 

251.03 

MAN-DAYS 

.  14 

TRAINING  EFFORT 

ONE 

24.68 

MAN-DAYS 

.  01 

OVERALL- PRODUCTIVITY 

ONE 

13.20 

TASKS/MAN-DAY 

COMPLETION  TIME  TWO 

442.00 

DAYS 

TOTAL  EFFORT  TWO 

1 

,940.46 

MAN-DAYS 

QA  EFFORT  TWO 

500.66 

MAN-DAYS 

.26 

DEVELOP  EFFORT 

TWO 

875.04 

MAN-DAYS 

.45 

REWORK  EFFORT  TWO 

257.82 

MAN-DAYS 

.13 

TESTING  EFFORT 

TWO 
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MAN-DAYS 

.  13 

TRAINING  EFFORT 

TWO 
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MAN-DAYS 

.  03 

OVERALL-PRODUCTIVITY 
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3 . 16 
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TOTAL  EFFORT  -  BOTH 

3 

,788.37 

MAN-DAYS 

Figure  72.  Simulation  5 — Statistical  Results 


99 


Figure  73.  Simulation  5 — Graph  1 
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6.  T2T1F2  and  T1T2F2 


Similar  to  the  fifth  simulation,  the  effect  of  the 
change  in  this  run  of  the  model  was  to  simulate  a  manager 
who  is  more  willing  to  transfer  workforce  by  force  from  the 
other  project  to  meet  his  manpower  needs.  These  variables 
(T2T1F2  and  T1T2F2)  model  willingness  to  force  transfers  as 
a  function  of  the  percent  reported  completed  of  the  second 
project.  They  are  originally  set  to  values  which  indicate 
an  unwillingness  on  the  manager's  part  to  force  transfers 
from  a  project  just  beginning.  This  is  because  the  manager 
realizes  the  importance  of  not  disrupting  a  project  in  its 
early  stages,  when  it  is  building  on  its  core  team.  Thus 
even  though  project  one  has  priority,  its  manager  would  not 
be  willing  to  force  transfers  from  project  two  because  he 
knew  it  was  in  its  "building  up"  stage.  In  this  case  both 
the  variable  affecting  project  one  and  its  equivalent 
(T2T1F2  and  T2T1F2)  were  increased  in  value  such  that  this 
period  of  non-disruption  is  denied.  The  default  values  of 
these  variables  are  0/ . 2/ . 5/ . 9/1/1  while  the  new  values  as 
used  in  this  simulation  are  1/1/1/1/i/l.  The  reader  is 
reminded  that  values  such  as  these  represent  table  functions 
in  the  Dynamo  language.  In  table  functions  each  number  is 
associated  with  the  occurrence  of  an  event.  For  instance, 
in  this  example,  a  manager  would  have  "0"  willingness 
to  force  transfers  when  project  two  was  reporting  zero 
percent  completion.  A  more  detailed  discussion  of  the  table 
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function  and  its  application,  while  beyond  the  scope  of  this 
work,  can  be  found  in  Alexander  Pugh's  book,  Dvnamo  User's 
Manual .  However,  in  several  cases  these  types  of  values  are 
included  in  the  description  of  the  simulation  to  enable 
duplication  of  these  simulations  in  follow-up  research. 
Results  from  this  simulation  are  given  in  Figures  75,  76, 
and  77. 

7.  TB2T11  and  TB1T21 

In  this  simulation  another  variable  and  its 
equivalent  (TB2T11  and  TB1T21)  were  changed.  These 
variables  are  used  in  conjunction  with  those  described  in 
simulation  eight  to  ascertain  the  overall  fraction  of  his 
workforce  the  manager  can  be  forced  to  transfer.  These 
variables  provide  input  to  this  fraction  as  a  function  of 
the  percent  reported  completed  of  the  second  project.  In 
the  default  situation  project  one  will  not  force  transfers 
from  project  two  at  all  until  it  is  at  least  ten  percent 
complete.  The  contribution  of  these  two  variables  is  zero 
until  this  time  causing  a  zero  fraction  of  the  workforce  to 
be  forcibly  transferred.  The  change  effected  in  this 
simulation  was  such  that  these  variables  no  longer  had  any 
affect  on  the  overall  fraction  of  the  workforce  to  be 
transferred — a  simulation  which  could  be  used  to  ascertain 
if  the  concept  which  these  variables  model  is  an  actual 
concern  of  managers.  If  the  change  does  not  produce 
significantly  different  results  from  the  baseline  case,  then 
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PROJECT  STATISTICS: 


PORTION  OF 
TOTAL  EFFORT 


COMPLETION  TIME  ONE 

414.50 

DAYS 

TOTAL  EFFORT  ONE 

1 

,  845.28 

MAN-DAYS 

QA  EFFORT  ONE 

421.44 

MAN-DAYS 

.23 

DEVELOP  EFFORT 

ONE 

884.82 

MAN-DAYS 

.48 

REWORK  EFFORT  ONE 

265.80 

MAN-DAYS 

.  14 

TESTING  EFFORT 

ONE 

248.54 

MAN-DAYS 

.  13 

TRAINING  EFFORT 

ONE 

24 . 68 

MAN-DAYS 

.01 

OVERALL-PRODUCTIVITY 

ONE 

13.22 

TASKS/MAN-DAY 

COMPLETION  TIME  TWO 

440.50 

DAYS 

TOTAL  EFFORT  TWO 

1 

,944.95 

MAN-DAYS 

QA  EFFORT  TWO 

500.95 

MAN-DAYS 

.26 

DEVELOP  EFFORT 

TWO 

875.72 

MAN-DAYS 

.45 

REWORK  EFFORT  TWO 

257.96 

MAN-DAYS 

.  13 

TESTING  EFFORT 

TWO 

260.62 

MAN-DAYS 

.  13 

TRAINING  EFFORT 

TWO 

49.70 

MAN-DAYS 

.03 

OVERALL- PRODUCTIVITY 

TWO 

12.55 

TASKS/MAN-DAY 

NET  TRANSFERS  2  TO  1 

-  3.28 

MEN 

NET  TRANSFERS  1  TO  2 

3 . 28 

MEN 

TOTAL  EFFORT  -  BOTH 

3 

,790.23 

MAN-DAYS 

Figure  75.  Simulation  6 — Statistical  Results 
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Figure  76.  Simulation  6 — Graph  1 


Figure  77.  Simulation  6 — Graph  2 


this  variable  has  little  effect  on  the  manager's  decision. 
The  default  values  of  these  variables  are  0/ . 2/ . 5/ . 9/1/1  and 
the  values  on  which  this  simulation  were  based  are 
l/l/l/l/l/l.  Figures  78,  79,  and  80  illustrate  the  results. 

8.  TC2T11  and  TC1T21 

In  this  simulation  the  variable  affecting  the 
fraction  of  his  workforce  a  manager  can  be  forced  to 
transfer  as  a  function  of  the  cumulative  recentness  of 
transfers  and  its  equivalent  in  the  other  project  are 
increased  (TC2T11  and  TC1T21) .  These  variables  are  used  in 
conjunction  with  those  described  in  simulation  seven  to 
ascertain  the  overall  fraction  of  his  workforce  the  manager 
can  be  forced  to  transfer.  The  default  values  of  these 
variables  (11  values  ranging  from  .5  to  zero)  are  such  that 
if  a  manager  has  recently  transferred  out  a  large  portion  of 
his  workforce  he  will  not  be  forced  to  transfer  any  more 
individuals  at  the  present  time.  These  values  were 
increased  (all  11  values  are  now  equal  to  the  value  one) . 

The  change  effected  in  this  simulation  was  such  that  these 
variables  no  longer  had  any  affect  on  the  overall  fraction 
of  the  workforce  to  be  transferred — a  simulation  which  could 
be  used  to  ascertain  if  the  concept  which  these  variables 
model  is  an  actual  concern  of  managers.  If  the  change  does 
not  produce  significantly  different  results  from  the 
baseline  case  than  this  variable  has  little  effect  on  the 
manager's  decision.  Figures  81,  82,  and  83  pertain. 
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PROJECT  STATISTICS: 

COMPLETION  TIME  ONE 

414.50 

PORTION  OF 
TOTAL  EFFORT 

DAYS 

TOTAL  EFFORT  ONE  _  1 

,845.33 

MAN-DAYS 

QA  EFFORT  ONE 

421.53 

MAN-DAYS 

.23 

DEVELOP  EFFORT  ONE 

884.84 

MAN-DAYS 

.48 

REWORK  EFFORT  ONE 

265.80 

MAN-DAYS 

.14 

TESTING  EFFORT  ONE 

248.48 

MAN-DAYS 

.  13 

TRAINING  EFFORT  ONE 

24.68 

MAN-DAYS 

.01 

OVERALL-PRODUCTIVITY  ONE 

13.22 

TASKS/MAN-DAY 

COMPLETION  TIME  TWO 

440.50 

DAYS 

TOTAL  EFFORT  TWO  1 

,944.72 

MAN-DAYS 

QA  EFFORT  TWO 

500.88 

MAN-DAYS 

.26 

DEVELOP  EFFORT  TWO 

875.78 

MAN-DAYS 

.45 

REWORK  EFFORT  TWO 

257.95 

MAN-DAYS 

.  13 

TESTING  EFFORT  TWO 

260.48 

MAN-DAYS 

.13 

TRAINING  EFFORT  TWO 

49.64 

MAN-DAYS 

.03 

OVERALL-PRODUCTIVITY  TWO 

12.55 

TASKS/MAN-DAY 

NET  TRANSFERS  2  TO  1 

-  3.28 

MEN 

NET  TRANSFERS  1  TO  2 

3.28 

MEN 

TOTAL  EFFORT  -  BOTH  3 

,790.05 

MAN-DAYS 

Figure  78.  Simulation  7 — Statistical  Results 
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DAYS 


Figure  80.  Simulation  7 — Graph  2 


PROJECT  STATISTICS: 


PORTION  OF 
TOTAL  EFFORT 


COMPLETION  TIME  ONE 

403.00 

DAYS 

TOTAL  EFFORT  ONE 

1 

,924.12 

MAN-DAYS 

QA  EFFORT  ONE 

431.44 

MAN-DAYS 

.22 

DEVELOP  EFFORT 

ONE 

919.38 

MAN-DAYS 

.48 

REWORK  EFFORT  ONE 
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MAN-DAYS 

.14 

TESTING  EFFORT 

ONE 
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MAN-DAYS 

.  14 

TRAINING  EFFORT 

ONE 

24.34 

MAN-DAYS 

.01 

OVERALL- PRODUCTIVITY 

ONE 

12.68 

TASKS/MAN-DAY 

COMPLETION  TIME  TWO 

456.50 

DAYS 

TOTAL  EFFORT  TWO 

2 

,027.95 

MAN-DAYS 

QA  EFFORT  TWO 

537.95 

MAN-DAYS 

.27 

DEVELOP  EFFORT 

TWO 

919.06 

MAN-DAYS 

.45 

REWORK  EFFORT  TWO 
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MAN-DAYS 

.13 

TESTING  EFFORT 

TWO 

263.22 

MAN-DAYS 

.13 

TRAINING  EFFORT 

TWO 

45.64 

MAN-DAYS 

.02 

OVERALL- PRODUCTIVITY 

TWO 

12.03 

TASKS/MAN-DAY 

NET  TRANSFERS  2  TO  1 

-  3.80 

MEN 

NET  TRANSFERS  1  TO  2 

3.80 

MEN 

TOTAL  EFFORT  -  BOTH 

3 

,952.07 

MAN-DAYS 

Figure  81.  Simulation  8 — Statistical  Results 
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Figure  82.  Simulation  8 — Graph  1 


Figure  83.  Simulation  8 — Graph  2 
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9. 


FORGETa 

In  the  ninth  simulation,  the  time  it  takes  a  manager 
to  "forget"  about  recent  transfers  (FORGET)  was  decreased 
from  the  default  value  of  60  to  30.  This  variable  affects 
the  willingness  of  that  manager  to  transfer  more  of  his 
workforce.  The  lower  the  value  of  this  variable,  the  more 
apt  the  manager  is  to  allow  transfers  as  he  has  already 
forgotten  about  relatively  recent  transfers.  Results  are 
provided  in  Figures  84,  85,  and  86. 

10.  FORGETb 

The  amount  of  time  it  takes  a  manager  to  "forget" 
about  recent  transfers  (FORGET)  was  increased  over  the 
default  value  from  60  to  120.  More  information  is  provided 
in  the  description  of  simulation  nine.  See  the  results  in 
Figures  87,  88,  and  89. 

11.  TMP1R2  and  TMP1R1 

In  this  experiment,  the  impact  of  the  hiring  ceiling 
on  the  willingness  to  force  transfers  from  a  project  because 
its  workforce  could  be  replenished  is  changed  as  is  its 
equiva-lent  in  the  other  project  (TMP1R2  and  TMP1R1) .  This 
change  allows  simulation  of  a  situation  in  which  the  ceiling 
has  less  of  an  impact  on  the  final  decision  than  in  the 
baseline  case.  Note  that  the  result  of  the  change  is  less 
of  an  impact  although  the  default  values  of  these  variables 
were  increased  from  0/. 5/. 75/. 9/. 975/1/1/1/1/1/1  to  all 
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PROJECT  STATISTICS: 


PORTION  OF 
TOTAL  EFFORT1 


COMPLETION  TIME  ONE- 

403.50 

DAYS 

TOTAL  EFFORT  ONE 

1 

,932.46 

MAN-DAYS 

QA  EFFORT  ONE 

431.22 

MAN-DAYS 

.22 

DEVELOP  EFFORT 

ONE 

922.17 

MAN-DAYS 

.48 

REWORK  EFFORT  ONE 
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MAN-DAYS 

.  14 

TESTING  EFFORT 

ONE 

278.50 

MAN-DAYS 

.14 

TRAINING  EFFORT 

ONE 

24.34 

MAN-DAYS 

.01 

OVERALL-PRODUCTIVITY 

ONE 

12.63 

TASKS/MAN-DAY 

COMPLETION  TIME  TWO 

451.50 

DAYS 

TOTAL  EFFORT  TWO 

2 

,008.27 

MAN-DAYS 

QA  EFFORT  TWO 

523.42 

MAN-DAYS 

.26 

DEVELOP  EFFORT 

TWO 

906.33 

MAN-DAYS 

.45 

REWORK  EFFORT  TWO 

260.13 

MAN-DAYS 

.  13 

TESTING  EFFORT 

TWO 

272.78 

MAN-DAYS 

.  14 

TRAINING  EFFORT 

TWO 

45.59 

MAN-DAYS 

.02 
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TWO 

12.15 
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NET  TRANSFERS  2  TO  1 

-  3.73 
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NET  TRANSFERS  1  TO  2 

3.73 
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TOTAL  EFFORT  -  BOTH 

3 
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MAN-DAYS 

Figure  84.  Simulation  9 — Statistical  Results 
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Figure  85.  Simulation  9 — Graph  1 
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PROJECT  STATISTICS: 
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MAN-DAYS 

.02 
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TASKS/MAN-DAY 

COMPLETION  TIME  TWO 

429.50 

DAYS 

TOTAL  EFFORT  TWO  1 
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MAN-DAYS 

QA  EFFORT  TWO 

500.57 

MAN-DAYS 

.26 

DEVELOP  EFFORT  TWO 
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MAN-DAYS 

.45 

REWORK  EFFORT  TWO 

259.70 

MAN-DAYS 

.13 

TESTING  EFFORT  TWO 
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MAN-DAYS 

.12 

TRAINING  EFFORT  TWO 
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.03 
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Figure  87.  Simulation  10 — Statistical  Results 
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0.  190.  299.  392.  400. 

DAYS 


one’s.  The  results  of  the  simulation  are  presented  in 
Figures  90,  91,  and  92. 

12.  TWRL2Tla  and  TWRLlT2a 

The  manager's  willingness  to  rely  on  the  release  of 
people  from  a  completing  project  and  its  equivalent  in  the 
other  project  are  the  independent  variables  in  this 
simulation  (TWRL2T1  and  TWRL1T2).  This  willingness  is  a 
ratio  of  the  time  remaining  (for  the  completing  project)  to 
the  hiring  delay;  the  higher  the  ratio,  the  less  apt  the 
manager  is  to  wait  in  the  baseline  scenario.  In  this 
simulation,  this  willingness  was  increased,  from 
1/. 5/. 25/. 1/0/0,  the  default  values,  to  l/l/l/l/l/l.  This 
increase  simulates  a  manager  who  is  always  willing  to  rely 
on  release  of  personnel  from  the  other  project  regardless  of 
how  much  longer  it  has  before  completion.  Figures  93,  94, 
and  95  provide  results. 

13.  TWRL2Tlb  and  TWRLlT2b 

Once  again,  the  manager's  willingness  to  rely  on  the 
release  of  people  from  a  completing  project  is  the 
independent  variable.  However,  in  this  case,  this 
willingness  was  decreased  from  the  default  values  given  in 
the  description  of  simulation  12  to  0/0/0/ 0/0/0.  This 
decrease  causes  the  situation  in  which  the  manager  will 
never  rely  on  people  from  the  other  project  based  on  its 
completion.  Figures  96,  97,  and  98  are  relevant. 
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PROJECT  STATISTICS: 
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1 

,944.64 

MAN-DAYS 

QA  EFFORT  TWO 

500.89 

MAN-DAYS 

.26 

DEVELOP  EFFORT 

TWO 

875.79 

MAN-DAYS 

.45 

REWORK  EFFORT  TWO 

257.95 

MAN-DAYS 

.  13 

TESTING  EFFORT 

TWO 

260.37 

MAN-DAYS 

.13 

TRAINING  EFFORT 

TWO 

49.64 

MAN-DAYS 

.03 

OVERALL-PRODUCTIVITY 

TWO 

12.55 

TASKS/MAN-DAY 

NET  TRANSFERS  2  TO  1 

-  3.28 

MEN 

NET  TRANSFERS  1  TO  2 

3.28 

MEN 

TOTAL  EFFORT  -  BOTH 

3 

,790.10 

MAN-DAYS 

Figure  90.  Simulation  11 — Statistical  Results 
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PROJECT  STATISTICS: 

PORTION 

OF 

TOTAL  EFFORT 

COMPLETION  TIME  ONE 

446.00 

DAYS 

TOTAL  EFFORT  ONE  1 

,791.38 

MAN-DAYS 

QA  EFFORT  ONE 

406.51 

MAN-DAYS 

.23 

DEVELOP  EFFORT  ONE 

880.55 

MAN-DAYS 

.49 

REWORK  EFFORT  ONE 

259.40 

MAN-DAYS 

.14 

TESTING  EFFORT  ONE 

244.11 

MAN-DAYS 

.  14 

TRAINING  EFFORT  ONE 

.81 

MAN-DAYS 

.00 

OVERALL-PRODUCTIVITY  ONE 

13.62 

TASKS/MAN-DAY 

COMPLETION  TIME  TWO 

439.00 

DAYS 

TOTAL  EFFORT  TWO  1 

,919.22 

MAN-DAYS 

QA  EFFORT  TWO 

494.75 

MAN-DAYS 

.26 

DEVELOP  EFFORT  TWO 

867.90 

MAN-DAYS 

.45 

REWORK  EFFORT  TWO 

258.23 

MAN-DAYS 

.13 

TESTING  EFFORT  TWO 

238.29 

MAN-DAYS 

.  12 

TRAINING  EFFORT  TWO 

60.05 

MAN-DAYS 

.03 

OVERALL-PRODUCTIVITY  TWO 

12.71 

TASKS/MAN-DAY 

NET  TRANSFERS  2  TO  1 

20.12 

MEN 

NET  TRANSFERS  1  TO  2 

-  20.12 

MEN 

TOTAL  EFFORT  -  BOTH  3 

,710.61 

MAN-DAYS 

Figure  93.  Simulation  12 — Statistical  Results 
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DAYS 


Figure  94.  Simulation  12 — Graph  1 


Figure  95.  Simulation  12- -Graph  2 


PROJECT  STATISTICS: 


PORTION  OF 
TOTAL  EFFORT 


COMPLETION  TIME  ONE 

467.00 

DAYS 

TOTAL  EFFORT  ONE 

1 

f  847.37 

MAN-DAYS 

QA  EFFORT  ONE 

454.38 

MAN-DAYS 

.25 

DEVELOP  EFFORT  i 

ONE 

864.41 

MAN-DAYS 

.47 

REWORK  EFFORT  ONE 

256.28 

MAN-DAYS 

.14 

TESTING  EFFORT  < 

ONE 

238.44 

MAN-DAYS 

.13 

TRAINING  EFFORT 

ONE 

33.85 

MAN-DAYS 

.  02 

OVERALL- PRODUCTIVITY 

ONE 

13.21 

TASKS/MAN-DAY 

COMPLETION  TIME  TWO 

408.50 

DAYS 

TOTAL  EFFORT  TWO 

1 

,935.44 

MAN-DAYS 

QA  EFFORT  TWO 

494.27 

MAN-DAYS 

.26 

DEVELOP  EFFORT 

TWO 

874.58 

MAN-DAYS 

.45 

REWORK  EFFORT  TWO 

263.04 

MAN-DAYS 

.14 

TESTING  EFFORT 

TWO 

234.08 

MAN-DAYS 

.12 

TRAINING  EFFORT 

TWO 

69.46 

MAN-DAYS 

.04 

OVERALL-PRODUCTIVITY 

TWO 

12.61 

TASKS/MAN-DAY 

NET  TRANSFERS  2  TO  1 

11.12 

MEN 

NET  TRANSFERS  1  TO  2 

-  11.12 

MEN 

TOTAL  EFFORT  -  BOTH 

3 

,782.80 

MAN-DAYS 

Figure  96.  Simulation  13 — Statistical  Results 
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Figure  97.  Simulation  13 — Graph  1 


DAYS 

Figure  98.  Simulation  13 — Graph  2 


14 .  Summary 


One  of  the  simulations  of  interest  in  experiment  set 
three  is  simulation  four  in  which  the  workforce  ceiling 
allocation  policy  is  changed  from  50:50  to  one  in  which  the 
project  with  priority,  project  one,  is  able  to  hire  up  to 
the  workforce  ceiling.  Project  two  can  only  hire  if  project 
one's  hiring  does  not  reach  the  ceiling.  This  simulation  is 
of  interest  when  compared  to  its  equivalent  in  experiment 
set  two  xn  which  costs  skyrocketed  when  this  variable  was 
changed.  This  does  not  happen  in  experiment  set  three.  The 
explanation  for  this  is  that  in  experiment  set  three, 
project  two  has  started  first  with  project  one  starting  at 
time  100.  Until  project  one  starts,  project  two  is  able  to 
acquire  and  assimilate  new  workers  early  in  its  development. 
This  leads  to  increased  productivity  over  the  life  of 
project  two.  The  result  of  this  increased  productivity  is 
less  difference  in  cost  between  this  simulation  and  the 
baseline  than  was  seen  in  experiment  set  two. 

This  type  of  analysis,  in  which  results  of 
simulations  are  compared  across  experiment  sets,  is  one  area 
which  warrants  more  attention.  Also  of  import  is  analysis 
of  the  results  within  this  experiment  set.  The  analysis 
will  provide  more  understanding  of  the  complex  and 
interrelated  variables  affecting  software  project 
management. 
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V.  CONCLUSIONS  AND  SUGGESTIONS  FOR  FURTHER  RESEARCH 


A.  CONCLUSIONS 

The  primary  objective  of  this  thesis,  to  extend  the 
System  Dynamics  model  of  software  project  management  to  a 
multiproject  environment,  has  been  met.  The  extended  model 
includes  changes  which  were  relatively  narrow  in  scope,  such 
as  the  addition  of  the  start  date  variable  and  the  addition 
of  arrays.  It  also  includes  major  changes  to  the  human 
resource  management  subsystem.  Identification  and  addition 
of  variables  to  reflect  the  considerations  managers  must 
ponder  when  determining  how  and  in  what  numbers  to  transfer 
people  as  well  as  those  variables  necessary  to  maintain 
organizational  balance  provided  insight  into  the  mechanisms 
of  human  resource  management.  Chapter  III  is  devoted  to  an 
explanation  of  these  insights.  Work  in  this  area  provided 
the  information  identified  under  the  second  of  the  three 
items  listed  in  the  "Thesis  Objectives"  section  in  Chapter 
II. 

The  first  item  identified  in  that  list,  that  of  gleaning 
information  on  the  effects  of  management  manpower  decisions 
on  the  allocation  of  resources  to  different  projects,  was 
addressed  in  the  experiment  sets  described  in  Chapter  IV. 

It  becomes  obvious  that  the  way  in  which  manpower  is 
allocated  within  an  organization  and  transferred  between 
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projects  impacts  greatly  on  the  combined  cost  of  the 
projects.  The  experiments  run  with,  for  example,  changes  to 
the  nominal  ceiling  on  the  workforce  (NCLTWF)  and  to  the 
workforce  ceiling  allocation  policy  (P0LCY1)  illustrate  this 
point. 

The  last  item  listed  in  Chapter  II  was  that  of  gaining 
insights  on  optimizing  the  staffing  function  in  a 
multiproject  environment.  Again,  the  experiment  sets 
presented  in  Chapter  IV,  particularly  the  first  set,  provide 
information  in  this  area.  Of  interest  is  the  fact  that  how 
priority  is  set,  dynamically  or  statically,  and  what  project 
has  priority  affects  the  optimal  overlap  to  minimize  cost. 
There  is  no  one  optimal  overlap  for  all  situations — it  is 
dependent  on  the  various  factors  relevant  to  any  software 
development  situation.  Comparison  of  the  results  in 
experiment  set  two  and  three  and  comparisons  between  the  two 
experiment  sets  also  provide  insight  into  optimizing  the 
staffing  function.  Of  interest  in  regard  to  optimization  of 
the  staff  function  are  those  variables  which,  when  changed, 
cause  little  or  no  change  in  the  cost  of  the  projects.  This 
result  indicates  that  those  variables,  such  as  hiring  and 
transferring  aggressiveness  (TAGRSV)  in  experiment  set  two, 
do  not  affect  costs  and  should  therefore  not  be  an  item  of 
concern  to  managers. 
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B.  SUGGESTIONS  FOR  FURTHER  RESEARCH 


This  thesis  provides  a  starting  point  for  further 
research  areas  in  several  arenas.  One  of  those  is 
development  of  an  expert  system  to  automatically  provide  the 
manager  with  the  optimal  overlap  to  minimize  cost  given  a 
certain  scenario.  The  results  presented  in  experiment  set 
one  were  manually  attained — a  process  no  software  project 
manager  would  have  the  time  or  inclination  to  undertake. 

Another  area  for  further  research  is  expansion  of  this 
new  model  to  model  environments  in  which  more  than  two 
projects  are  underway.  Though  much  of  the  initial  work  in 
that  realm  has  been  completed  in  this  thesis,  the  real 
possibility  of  the  identification  of  other  variables 
affecting  manpower  decisions  in  this  type  of  environment 
exists. 

Perhaps  the  most  interesting  area  of  further  research  in 
this  arena  is  analysis  of  the  results  presented  in  this 
thesis.  Of  particular  interest  are  the  effects  of  changing 
the  workforce  ceiling  and  the  effects  of  changing  the  hiring 
and  transfer  aggressiveness  in  experiment  set  one.  In 
experiment  set  two,  the  cause  of  the  drastic  increase  in 
cost  when  the  workforce  allocation  policy  is  changed  is  an 
area  for  detailed  analysis.  The  lack  of  a  similar  spike  in 
experiment  set  three  is  also  of  interest.  Discussions  with 
software  project  managers  and  extensive  research  in  the 
software  project  management  field  would  be  necessary  to 
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explain  and  understand  these  results  as  presented  in  Chapter 
IV.  This  research  could  lead  to  identification  of  other 
variables  of  interest  and  further  refinement  of  this  model. 
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APPENDIX 


SUMMARY  RESULTS  OF  EXPERIMENT  SET  ONE 


BASELINE  SUMMARY  RESULTS 


Overlap 

Cost 

Project  1 

Cost 

Project  2 

Total  Cost 

0 

1823.02 

1868.73 

3691.75 

20 

1889.03 

1872.55 

3761.58 

40 

1930.09 

1911.51 

3841.60 

60 

1981.93 

1933.09 

3915.02 

80 

2042.72 

1940.13 

3982.85 

100 

2028.94 

1922.49 

3951.43 

120 

2017.60 

1912.12 

3929.72 

140 

1995.47 

1901.36 

3896.83 

160 

1996.06 

1934.22 

3930.28 

180 

1851.63 

1934.56 

3786.19 

200 

1894.76 

1958.21 

3852.97 

300 

1809.83 

1954.88 

3764.71 

400 

1828.68 

1954.80 

3783.48 

127 


TRANSFER  PRODUCTIVITY  SUMMARY  RESULTS 


Overlap 

Cost 

Project  1 

— 

Cost 

Project  2 

Total  Cost 

0 

1830.62 

1875.15 

3705.77 

20 

1925.49 

1876.01 

3801.50 

40 

1974.57 

1903.59 

3878.16 

60 

2021.36 

1936.28 

3957.64 

80 

2079.04 

1950.11 

4029.15 

100 

2070.94 

1937.74 

4008.68 

120 

2060.92 

1907.59 

3968.51 

140 

2042.19 

1916.54 

3958.73 

160 

2050.45 

1929.13 

3979.58 

180 

1854.15 

1915.05 

3769.20 

200 

1864.97 

1949.45 

3814.42 

300 

1803.54 

1954.96 

3758.50 

400 

1829.16 

1954.80 

3783.96 
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WORKFORCE  CEILING  SUMMARY  RESULTS 


Overlap 

Cost 

Project  1 

Cost 

Project  2 

Total  Cost 

0 

1886.37 

1877.54 

3763.91 

20 

1906.43 

1896.12 

3802.55 

40 

1944.19 

1902.30 

3846.49 

60 

1951.44 

1898.79 

3850.23 

80 

1926.71 

1900.11 

3826.82 

100 

1914.38 

1903.10 

3817.48 

120 

1914.46 

1902.29 

3816.75 

140 

1900.24 

1925.89 

3826.13 

160 

1916.09 

1922.27 

3838.36 

180 

1877.10 

1919.80 

3796.90 

200 

1833.97 

1922.21 

3756.18 

300 

1784.05 

1903.45 

3687.50 

400 

1779.82 

1903.24 

3683.06 

WORKFORCE  CEILING  AND  ALLOCATION  SUMMARY  RESULTS 


Overlap 

Cost 

Project  1 

— 

Cost 

Project  2 

Total  Cost 

0 

1861 . 66 

1853.74 

3715.40 

20 

1845.11 

1862.71 

3707.82 

40 

1865.97 

1883.68 

3749.65 

60 

1879.48 

1896.63 

3776.11 

80 

1874.08 

1899.39 

3773.47 

100 

1889.40 

1910.62 

3800.02 

120 

1897.66 

1918.52 

3816.18 

140 

1921.20 

1912.20 

3833.40 

160 

1840.53 

1874.45 

3714.98 

180 

1830.52 

1891.50 

3722.02 

200 

1842.35 

_ 

1908.62 

3750.97 

300 

1962.25 

1987.12 

3949.37 

400 

1856.66 

2030.46 

3887.12 
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HIRING  AND  TRANSFERRING  AGGRESSIVENESS  SUMMARY  RESULTS 


Overlap 

Cost 

Project  1 

Cost 

Project  2 

Total  Cost 

0 

1920.76 

1904.95 

3825.71 

20 

1944.36 

1901.39 

3845.75 

40 

2006.75 

1930.78 

3937.53 

60 

2084.35 

1947.30 

4031.65 

80 

2135.07 

1955.63 

4090.70 

100 

2116.13 

1937.46 

4053.59 

120 

2023.54 

1914.06 

3937.60 

140 

2047.54 

1907.27 

3954.81 

160 

2112.06 

1901.34 

4013.40 

180 

1876.49 

1950.46 

3826.95 

200 

1932.36 

1977.71 

.. 

3910.07 

300 

1816.91 

1962.76 

3779.67 

400 

1842.20 

1962.75 

3804.95 
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PROJECT  STARTING  FIRST  HAS  PRIORITY  SUMMARY  RESULTS 


Overlap 

Cost 

Project  1 

Cost 

Project  2 

Total  Cost 

0 

1810.49  __ 

2025.21 

3835.70 

20 

1803.50 

2044.93 

3848.43 

40 

1813.53 

2107.38 

3920.91 

60 

1829.74 

2083.19 

3912.93 

80 

1840.69 

1906.84 

3747.53 

100 

1852.70 

1838.67 

3691.37 

120 

1863.02 

1827.91 

3690.93 

140 

1885.53 

1820.44 

3705.97 

160 

1904.28 

1828 . 84 

3733 . 12 

180 

1934.56 

1851.63 

3786.19 

200 

1958.21 

1894.76 

3852.97 

300 

1954.88 

1809.83 

3764.71 

400 

1954.80 

1828 . 68 

3783.48 
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PROJECT  STARTING  LAST  HAS  PRIORITY  SUMMARY  RESULTS 


Overlap 

Cost 

Project  1 

Cost 

Project  2 

Total  Cost 

0 

1810.49 

2025.21 

3835.70 

20 

1805.90 

2013.98 

3819.88 

40 

1825.74 

2010.19 

3835.93 

60 

1837.31 

1967.22 

3804.53 

80 

1841.82 

1949.91 

3791.73 

100 

1845.33 

1944.72 

3790.05 

120 

1859.30 

1945.46 

3804.76 

140 

1845.87 

1948.48 

3794.35 

160 

1849.84 

1950.32 

3800.16 

180 

2050.06 

1909.19 

3959.25 

200 

1958.82 

1904.26 

3863.08 

300 

1809.83 

1954.88 

3764.71 

400 

1828.68 

1954.80 

3783.48 
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